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SUBJECT Topics for Discussion at the Forthcoming 

Meeting 



First, I apologise humbly for having to postpone the meeting 
scheduled for 3 May 1963 in Palo Alto. The ARPA Command it Con- 
trol Research office has just been assigned a new task that must be 
activated immediately, and I must devote the whole of the coming 
week to it. The priority is externally enforced. I am extremely 
sorry to inconvenience those of you who have made plans for May 3rd. 
Inasmuch as I shall be in Cambridge the rest of this week, I am asking 
my colleagues here to re-schedule the meeting, with May 10th, Palo 
Alto, as target time and place. 

The need for the meeting and the purpose of the meeting are things 
that I feel intuitively, not things that I perceive in clear structure. I 
am afraid that that fact will be too evident in the following paragraphs. 
Nevertheless, I shall try to set forth some background material and 
some thoughts about possible interactions among the various activities 
in the overall enterprise for which, as you may have detected in the 
above-Subject, I am at a loss for a name. 

In the first place, it is evident that we have among ub a collection 
of individual (personal and/or organizational) aspirations, efforts, 
activities, and projects. These have in common, I think, the charact- 
eristics that they are in some way connected with advancement of Uy> 
art or technology of information processing, the advancement of intel- 
lectual capability (man, man-machine, or machine), and the approach 
to a theory of science. The individual parts are, at least to some ex- 
tent, mutually interdependent. To make progress, each of the active 
research needs a software base and a hardware facility more complex 
and more extensive than he, himself, can create in reasonable time. 
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In pursuing the individual objectives, various members of the group 
will be preparing executive and monitoring routines, languages and 
compilers, debugging systems and documentation schemes, and sub- 
stantive computer programs of more or less general usefulness. One 
of the purposes of the meeting- -perhaps the main purpose- -is to explore 
the possibilities for mutual advantage in these activities- -to determine 
who is dependent upon whom for what and who may achieve a bonus bene- 
fit from which activities of what other members of the group. It will be 
necessary to take into account the costs as well as the values, of course. 
Nevertheless, it seems to me that it is much more likely to be advantage- 
ous than disadvantageous for each to see the others' tentative plans be- 
fore the plans are entirely crystalized. I do not mean to argue that 
everyone should abide by some rigid system of rules and constraints that 
might maximize, for example, program interchangeability. But, I do 
think that we should see the main parts of the Beveral projected efforts, 
all on one blackboard, so that it will be more evident than it would other- 
wise be, where network-wide conventions would be helpful and where in- 
dividual concessions to group advantage would be most important. 

It is difficult to determine, of course, what constitutes "group advan- 
tage." Even at the risk of confusing my own individual objectives (or 
ARPA's) with those of the group, " however, let me try to set forth some 
of the things that might be, in some sense, group or system or network 
desiderata. 

There will be programming languages, debugging languages, time-shar- 
ing system control languages, computer-network languages, data-base 
(or file-storage-and-retrieval languages), and perhaps other languages as 
well. It may or may not be a good idea to oppose or to constrain lightly 
the proliferation of such. However, there seems to me to be little ques- 
tion that it is desirable to foster "transfer of training" among these lan- 
guages. One way in which transfer can be facilitated is to follow group 
consensus in the making of the arbitrary and nearly- arbitrary decisions 
that arise in the design and implementation of languages. There would be 
little point, for example, in having a diversity of symbols, one for each 
individual or one for each center, to designate "contents of or "type the 
contents of." It seems to me desirable to have as much homogenity as 
can reasonably be achieved in the set of sub-languages of a given language 
system — the system, for example, of programming, debugging, and time- 
sharing-control languages related to JOVIAL on the Q-32, or the system 
related to Algol (if such were developed and turned out to be different from 
the JOVIAL, set) for the Q-32 computer, or the set related to FORTRAN for 
a 7090 or a 7094. 



Dictating the foregoing paragraph led me to see more clearly than 
I had seen it before that the problem of achieving homogeneity within 
a set of correlated languages is made difficult by the fact that there will 
be, at a give time, only one time- sharing system in operation on a given 
computer, whereas more than one programming language with its asso- 
ciated debugging language may be simultaneously in use. The time-shar- 
ing control language can be highly correlated only with one programming 
and debugging language pair. Insofar as syntax is concerned, therefore, 
it seems that it may be necessary to have a "preferred" language for each 
computer facility or system, and to have the time -sharing control langu- 
age be consistent with the preferred, j Insofar as semantics is concerned-- 
or, at least, insofar as the association of particular symbols with parti- 
cular control functions is concerned--I see that it would be possible, 
though perhaps inconvenient, to provide for the use, by several different 
operators, of several different specific vocabularies » Anyway, there 
seems to me to be a problem, or a set of problems, in this area. 

There is an analogous problem, and probably a more difficult one, in 
the matter of language for the control of a network of computers. Con- 
sider the situation in which several different centers are netted together, 
each center being highly individualistic and having its own special language 
and its own special way of doing things. Is it not desirable, or even neces- 
sary, for all the centers to agree upon some language or, at least, upon 
some conventions for asking such questions as "What language do you 
speak?" At this extreme, the problem is essentially the one discussed 
by science fiction writers: "How do you get communications started among 
totally uncorrelated "sapient" beings?" But, I should not like to make an 
extreme assumption about the uncorellatedness . (I am willing to make an 
extreme assumption about the sapience.) The more practical set of ques- 
tions is: Is the network control language the same thing as the time- 
sharing control language? (If so, the implication is that there is a com- 
mon time-sharing control language.) Is the network control language dif- 
ferent from the time-sharing control language, and is the network-control 
language common to the several netted facilities? Is there no such thing 
as a network-control language? (Does one, for example, simply control 
his own computer in such a way as to connect it into whatever part of the 
already-operating net he likes, and then shift over to an appropriate mode?) 

In the foregoing paragraphs, I seem to have lept into the middle of 
complexity. Let me approach from a different starting point. Evidently, 
one or another member of this enterprise will be preparing a compiler, or 
compilers, for modifying existing programs that compile FORTRAN, 
JOVIAL, ALGOL, LISP and IPL-V (or V-l, or V-ll). If there is more than 
one of any one of the foregoing, or of any one of others that I do not foresee, 
then it seems worthwhile to examine the projected efforts for compatibility. 
Moreover, to me, at least, it seems desirable to examine the projected 



efforts to see what their particular features are, and to see whether there 
is any point in defining a collection of desirable features and trying to get 
them all into one language and one system of compilers. I am impressed 
by the argument that list-structure features are important as potential el- 
ements of ALGOL or JOVIAL, that we should think in terms of incorporat- 
ing list -structure features into existing languages quite as much as in 
terms of constructing languages around list-structures. 

It will possibly turn out, I realize, that only on rare occasions do most 
or all of the computers in the overall system operate together in an integrat- 
ed network. It seems to me to be interesting and important, nevertheless, 
to develop a capability for integrated network operation. If such a network 
as I envisage nebulously could be brought into operation, we would have at 
least four large computers, perhaps six or eight small computers, and a 
great assortment of disc files and magnetic tape units --not to mention the 
remote consoles and teletype stations--all churning away. It seems easiest 
to approach this matter from the individual user's point of view--to see 
what he would like to have, what he might like to do, and then to try to fig- 
ure out how to make a system within which his requirements can be met. 
Among the things I see that a user might want to have, or to do, are the 
following: 

(Let me suppose that I am sitting at a console that includes cathode-ray- 
tube display, light-pen, and typewriter.) I want to retrieve a set of experi- 
mental data that is on a tape called Listening Tests. The data are called 
"experiment 3." These data are basically percentages for various signal- 
to-noise ratios. There are many such empirical functions. The experiment 
had a matrix design, with several listeners, several modes of presentation, 
several signal frequencies, and several durations. I want, first, to fit 
some "theoretical" curves to the measured data. I want to do this in a pre- 
liminary way to find out what basic function I want to choose for the theoret- 
ical relation between percentage and signal-to-noise ratio. On another tape, 
called "Curve Fitting," I have some routines that fit straight lines, power 
functions, and cumulative normal curves. But, I want to try some others, 
also. Let me try, at the beginning, the functions for which I have programs. 
The trouble 4s, I do not have a good grid-plotting program. I want to bor- 
row one. .Simple, rectangular coordinates will do, but I would like to spec- 
ify how many divisions of each scale there should be and what the labels 
should be. I want to put that information in through my typewriter. Is 
there a suitable grid-plotting program anywhere in the system? Using pre- 
valling network doctrine, I interrogate first the local facility, and then 
other centers. Let us suppose that I am working at SDC, and that 1 find a 
program that looks suitable on a disc file in Berkeley. My programs were 
written in JOVIAL. The programs I have located through the system were 
written in FORTRAN. I would like to bring them in as relocatable binary 



programs and, using them as subroutines, from my curve-fitting programs, 
either at "bring-in time" or at "run-time." 

Supposing that I am able to accomplish the steps just described, let us 
proceed. I find that straight lines, cubics, quintics, etc., do not provide 
good fits to the data. The best fits look bad when I view them on the oscil- 
loscope . 

The fits of the measured data to the cumulative normal curve are not 
prohibitively bad. I am more interested in finding a basic function that I 
can control appropriately with a few perimeters than 1 am in making con- 
tact with any particular theory about the detection process, so I want to 
find out merely whether anyone in the system has any curve-fitting pro- 
grams that will accept functions supplied by the user or that happen to have 
built-in functions roughly like the cumulative normal curve, hit assymmet- 
rical. Let us suppose that I interrogate the various files, or perhaps inter- 
rogate a master-integrated, network file, and find out that no such programs 
exist. I decide, therefore, to go along with the normal curve. 

At this point, I have to do some programming. I want to hold on to my 
data, to the programs for normal curve fitting, and to the display programs 
that I borrowed. What I want to do is to fit cumulative normal curves to my 
various sub-sets of data, constraining the mean and the variance to change 
slowly as I proceed along any of the ordinal or ratio-scale dimensions of my 
experiment, and permitting slightly different sets of perimeters for the 
various subjects. So, what I want to do next is to create a kind of master 
program to set perimeter values for the curve-fitting routines, and to dis- 
play both the graphical fits and the numerical measures of goodness of fit 
as, with light-pen and graphs of perimeters versus independent variables 
on the oscilliscope screen, I set up and try out various (to me) reasonable 
configurations. Let us say that I try to program this in JOVIAL, but that 
I have to test the new program repeatedly on my actual data, with the sub- 
ordinate programs already mentioned, until 1 get the thing to work. 

Let us suppose that I finally do succeed, that I get some reasonable re- 
sults, photograph the graphs showing both the empirical data and the 
"theoretical" curves, and retain for future use the new programs. I want 
to make a Bystern of the whole set of programs and Btore it away under the 
name "Constrained-perimeter Normal-curve-fitting System. " But, then 
suppose that my intuitively natural way of naming the system is at odds 
with the general guidelines of the network for naming programs. I would 
like to have this variance from convention called to my attention, for I am 
a conscientious organisation man" when it comes to matters of program 
libraries and public files of useful data. 
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In the foregoing, I must have exercised several network features. 
I engaged in information retrieval through some kind of a system that 
looked for programs to meet certain requirements I had in mind. Pre- 
sumably, this was a system based upon descriptors, or reasonable 
facsimiles thereof, and not, in the near future, upon computer appre- 
ciation of natural language. However, it would be pleasant to use some 
of the capabilities of avant-garde linguistics. In using the borrowed 
programs, I effected some linkages between my programs and the bor- 
rowed ones. Hopefully, I did this without much effort — hopefully, the 
linkages were set up — or the basis for making them was set up — when 
the programs were brought into the part of the system that I was using. 
I did not borrow any data, but that was only because I was working on 
experimental data of my own. If I had been trying to test some kind of 
a theory, I would have wanted to borrow data as well as programs. 

When the computer operated the programs for me, I suppose that the 
activity took place in the computer at SDC, which is where we have been 
assuming I was. However, I would just as soon leave that on the level 
of inference. With a sophistocated networks ontrol system, I would not 
decide whether to send the data and have them worked on by programs 
somewhere else, or bring in programs and have them work on my data. . 
I have no great objection to making that decision, for a while at any rate, 
but, in principle, it seems better for the computer, or the network, 
somehow, to do that. 

At the end of my work, I filed some things away, and tried to do it in 
such a way that they would be useful to others. That called into play, 
presumably, some kind of a convention-monitoring system that, in its 
early stages, must almost surely involve a human criterian as well as 
machine processing. 

The foregoing (unfortunately long) example is intended to be a kind of 
example of example. I would like to collect, or see someone collect, a 
considerable number of such examples, and to see what kind of software 
tail hardware facilities they imply. I have it well in mind that one of the 
implications of a considerable number of such examples would be a very 
large random-access memory. 

Now, to take still another approach to this whole matter, let me string- 
together a series of thoughts that are coming to mind. (I was interrupted 
at this point, and the discussion almost has to take a turn. ) First, there 
is the question of "pure procedure. " I understand that the new version of 
JOVIAL is going to compile programs in "pure -procedure"^ style. Will 
the other compilers at the other centers do likewise? Second, there is the 
question of the inte rpretation, at one center, of requests directed to it from 
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another center. I visualize vaguely some kind of an interpretive system 
that would serve to translate the incoming language into commands or 
questions of the form in terms of which the interrogated center operates. 
Alternatively, of course, the translation could be done at the sending end. 
Still alternatively, the coordination could be so good that everybody spoke 
a common language and used a common set of formats. Third, there is 
the problem of protecting and updating public files. 1 do not want to use 
material from a file that is in the process of being changed by someone 
else. There may be, in our mutual activities, something approximately 
analogous to military security classification. If so, how will we handle 
it? 

Next, there is the problem of incremental compiling. Am I correct 
in thinking that Perlis, with his "threaded lists, " has that problem, and 
the related problem of compile-test-recompile, essentially solved? 

Over on the hardware side, I am worried that the boundry-registered 
problem, or more generally the memory-protection problem, may be ex- 
pensive to solve on the Q-32 and both difficult and expensive to solve on 
other machines, and I am worried that the problem of swapping or trans- 
ferring information between core and secondary memory will be difficult 
and expensive on 7090s and 7094s --and I worry that time-sharing will not 
be much good without fast swaps or transfers. What are the best thoughts 
on these questions? In what state are our several or collective plans? 

Implicit in the long example was the question of linking subroutines at 
run time. It is easy to do the calling, itself, through a Bimple directory, 
but it seems not to be so simple to hjjtndle system variables. Maybe it 
is simple in principle and perhaps I should say that it seems possibly in- 
feasible to handle the linking of system variables at run time through 
tables or simple indirect addressing schemes. 

It is necessary to bring this opus to a close because I have to go catch 
an airplane. I had intended to review ARPA's Command-aid- Control in- 
terests in improved man-computer interaction, in time-sharing and in 
computer networks. I think, however, that you all understand the reasons 
for ARPA's basic interest in these matters, and I can, if need be, review 
them briefly at the meeting. The fact is, as I see it, that the military 
greatly needs solutions to many or most of the problems that will arise if 
we tried to make good use of the facilities that are coming into existence. 
1 am hoping that there will be, in our individual efforts, enough evident 
advantage in cooperative programming and operation to lead us to solve 
the problems and) thus, to bring into being the technology that the military 
needs. When problems arise clearly in the military context and seem not 
to appear in the research context, then ARPA can take steps to handle them 
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on an ad hoc basis . As I say, however, hopefully, many of the problems 
will be essentially the same, and essentially as important, in the research 
context as in the military context. 

In conclusion, then, let me say again that I have the feeling we should 
discuss together at some length questions and problems in the set to which 
I have tried to point in the foregoing discussion. Perhaps I have not 
pointed to the important problems — certainly I have not pointed to all the 
problems. Hopefully, the discussion maybe a little less rambling than 
this effort that I am now completing. 

J. C. R. Licklider, Director^/)) 
Behavioral Sciences ' 
Command & Control Research 
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Mr. Robert Taylor 
Mr. Larry Roberts 
ODS/ARPA 
3E175 Pentagon 
Washington, D.C. 

Dear Bob and Larry, 

This Is in response to your note of April 2kth and the 
Message Switching Network Proposal which Larry handed me at the 
Spring Joint Computer Conference. 

I want to go on record as being in favor of the proposal 
for a PDP-8-lite machine at each node. It will strongly lend a 
uniformity to experimentation and to possible performance measure- 



We are still exploring possible Interest of people In 
Bieater Arts with respect to the ARPA docunKntary. I will let you 
taiow as soon as we hear something. 

Very truly yours, 



Message Switching Network Proposal 



After the Network discussion at the ARPA Contractors' Meeting, 
Wes Clark made a recommendation which deserves serious considera- 
tion as a method of implementing the proposed network. This plan 
was discussed privately by some of the people and is presented here 
to acquaint everyone with the concept. 

The plan considered in the general meeting was to connect all of 
the computers by phone lines and data sets so as to enable them to 
establish communication with any other node using a line switching 
technique. However, the basic function that would be performed by a 
small piece of each computer and the phone lines is to perform a 
message switching and transmission function. The concept which Wes 
proposed was to insert a small computer like the PDF- 8 between each 
participant's computer and the transmission line network. The small 
computer, an Interface Message Processer (IMP), would perform the 
functions of dial up, error checking, retransmission, routing and varifi- 
cation. Thus the set of IMP's plus the telephone lines and data sets 
would constitute a Message Switching ' Network . The protocol which we 
are intending to establish would define the communication format between 
the IMP's. The interface between the participant's computer and his 
IMP would now be a digital interface of a much simpler sort so that no 
considerations of error checking, retransmission and inter-network 
routing would have to be considered. Messages could be supplied which 
merely requested that a message be sent to another node stating the 
priorities for speed of transmission and, if desired, error probability. 
That is, if a message consists solely of non-critical data, it could be 
sent unchecked through the network at a lower cost. 

If the computer selected was the PDP-8, we could probably utilize 
the modified version which Gordon Bell is developing. This computer 
could most likely be mass purchassed from DEC thereby obtaining a 
very reasonable cost. Of course, other similar computers would be 
considered. Within the IMP there would be a section of program devoted 
to the network functions previously described. Some of the memory 
would be used for buffer space and some would be left free for additional 
program to re-format the information at the interface to the main computer. 

Disadvantages 

It is clear that the use of a small computer adds an additional cost to 
each installation of perhaps $20K. It is not clear what the saving, if any, 
would be in reduced cost for the main computer interface or what the 



The first is a proposed increase in our Network Subproject of $6M 
per year over the period of the current five-year force structure. 
An experimental system is proposed which would link three or more 
large general purpose time- sharing systems in a computer network 
creating two major capabilities not now possible: (1) the ability of 
a user to create, debug and execute pure procedure on-line from 
any node to any other node, and (2) the ability to use a recently 
changed procedure without regard to the node from which it was 
changed. Large scale information retrieval data banks as they are 
discussed in the technical and lay literature will remain in the realm 
of imagination until these two problems are solved. We are not able 
to initiate this project to the detriment of our present efforts in 
graphics, man-machine interaction, parallel processing, language 
development or physical interaction for these efforts will result in 
the applications necessary to users of the proposed network. 



saving in compute load -would be. Some people feel that their present com- 
puter could handle the data sets directly as easily as interfacing with a 
small computer since their computer would still have to consider which 
messages were for which users and utilize a protocol similar to the one 
used on the transmission network. Also, if an intelligent console such as 
the DEC 338 was used as a node in the network and it was required that an 
additional computer be used as an interface to the network, there would be 
a marked increase in the cost of the terminal. 

Advantages 

The major advantage of this plan is that a unified, straightforward 
design of the network can be made and implemented without undue consider- 
ation of the various contractors' buffer space, interpret speed and other 
machine requirements. The interface to the contractor's computer would 
be a much simpler digital connection with an additional flexibility provided 
by programming the IMP. The network section of the IMP'S program 
would be completely standard and provide guaranteed buffer space and 
uniform characteristics, thus the entire planning job is sustantially simpli- 
fied. The data sets and transmission lines utilized between the small com- 
puters would most likely be standardized upon, but as changes occurred in 
the communication tariffs or data rates available, it would be much more 
straightforward to modify just the small computer net rather than twenty 
different computers. As soon as the need became apparent, additional 
small computers could be located at strategic connection points within the 
network to concentrate messages over cross-country lines. Finally, the 
modifications required to currently operating systems would be substantially 
less if we utilized these small computers since there will be no require- 
ment to find buffer spaces, hold messages for retransmission, verify 
reception of messages and dial up telephone lines. 

The basic advantage of utilizing small computers to run a message 
switching network is an increased speed for the realization of the network, 
a decreased load on the main computer and improved flexibility as changes 
are required. The technique also provides a distinct network entity which 
is useful in presenting the network publically. In cases where a participant 
felt his computer should be used to connect to the telephone system directly, 
this would, of course, be possible if he followed the approved protocol and 
conventions; however, the requirements on his computer might be some- 
what more demanding as to required buffer space and message rerouting. 
If we agree that the use of the small computer is justified, we will need to 
develop an additional protocol for the interface between the small computer 
network program and its main computer formatting program. This protocol 
would not be extremely different from the telephone line protocol except 
that it would be defined in terms of data in memory words rather than on 



- . MEMORANDUM , June 6, "967 
" TO : Dan Bobrow and.Jert Sutherland 

FROM: J. C R. Licklider 

SUBJECT: 

The Purpose and Content of BONOFORM alias SUTHERN COMFORT 
Introduction 

Bobrow, Sutherland and Licklider constitute a committee of the 
ARPA network circle. .The purpose of the committee is in the 
general vicinity of x, where x Is to do something about protocol, 
formats, conventions, or language for messages transmitted 
through the ARPA network. The purpose of this memorandum is to 
clarify the purpose of the committee and to relate the general 
nature of the expected product of the committee to the context of 
the ARPA network. This memorandum will not describe the expected 
product. 

The expected product of the committee is a language for defining 
message forms of formats. As suggested opposite "Subject," I am 
proposing to call the language either "Bobrow Normal Form" or 
"Sutherland Network Communication Format." "Bonoform" has the 
advantage of compactness and will be used in the remainder of 
this memorandum. 

Context and Purpose 

The ARPA network circle meeting of May 18, 1967, decided, among 
other things, to adopt the Interface Message Processor concept 
and to use ASCII code and its rules without deviation in the 
interior communication language of the network. Each IMP will be 
either (preferably) a small computer or (acceptably) a functional 
part of a large one. In the former case, the interface between 
the local part of the node and the part of the node dominated 
by network-wide conventions will be a software-software inter- 
face inside the IMP. In the latter case, the part of, the large 
computer dominated by network-wide conventions will perforce look 
to the communication lines and to the rest of the node exactly 
like an IMP. The interior communication language, which I shall 



abbreviate INTERCOM (or Intercom, since - perhaps because of 
their relative unavailability - I prefer lower-case letters), Is 
the language that flows through the communication lines and 
switches and within the part of the IMPs that are dominated by 
network-wide conventions. The meeting of May 11 made progress 
toward the specification of format for Intercom messages. However, 
only the headers and trailers of such messages are strongly con- 
strained by the specifications. All that Is said about the bodies 
of such messages Is that they shall conform with the ASCII rules. 
Insofar as the body messages are made up of characters, the 
characters must be ASCII characters of seven identifying bits and 
one parity bit. Insofar as the body messages contain pure binary 
information, it must be 6-bit binary; the other two bits are pre- 
empted by ASCII constraints. 

As the primitive mind works, the next question concerns further 
specification of the language of the body (i.e., not Intercom 
header or trailer) messages. However, the minds ef two-thirds of 
the present committee are not primitive. The next question there- 
fore concerns not the body language itself but a language for 
describing the formats of body messages. This message- format- 
describing language is what I am calling Bonoform. 

Chalmers Sherwln has been (and is) advocating a system for handling 
the problem of formats for messages of the kind with which we 
are concerned. Two elements of his system are a standards office 
and a standard header. Anyone can Invent or define a format , send 
it to the standards office, and (if it meets the simple rules) have 
it registered, assigned a format number, and listed. Then, when 
he sends a message, he need only put the format number in its 
proper place in the standard header. In the body that follows 
the header, he transmits whatever the format calls for, and his 
recipient, who presumably has a copy of the format description, 
decodes, or interprets the message accordingly. 

Instead of relying on the standards office, of course, one could 
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send the format description as a message, providing the format 
of the format description were agreed upon by both sender and 
receiver. It is precisely the purpose of Bonoform to define the 
format of format description and other parts of the language 
of message descriptions. 

Schedule of Work 

At a committee meeting yesterday, the general character of 
Bonoform was agreed upon. It will be somewhat like Backus Normal 
Form. It will provide for assignments of character (I.e., charac- 
terization) and for assignments of value. All variables that may 
be .-^signed values will be global. Characterization may be 
hierarchical. That is, a format may be defined by a statement 
containing terms that are defined (i.e., formats that are 
characterized) in other statements. And so on. But the language 
is intended to be very simple. It will not be a programming 
language . 

Bobrow and Sutherland see problems arising, problems familiar 
to them in other experiences in the field of formal languages. 
Bobrow is going to write-up a preliminary description of the 
language and a brief discussion of the problems. 

Then there will be another committee meeting. 

The target date for unveiling of the language is July 1, 1967. 
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MEMORANDUM FOR THE DIRECTOR. PROGRAM MANAGEMENT 
SUBJECT: Interactive Computer Network Communication System 



The purpose of thie memorandum i* to request an ARPA order be written 
to ARG-Durham for $563 K to Initiate a contract for the design, construc- 
tion, installation, test and maintenance of interface message processors 
(IMPs) to form a communication system to support the ARPA network 
activities. The contractor is to be selected by competition between 
selected bidders. 

APP .Mo. 723, submitted vith this memorandum, describes the require- 
ments for a network .ind the need for a distributed store and forward com- 
munications system. A detailed specification has been written to permit 
potential contractors to bid on proviiing the IMPs. This bid will be for 
total system responsibility. 3idders vho are not computer manufacturers 
must therefore negotiate vith a manufacturer on the price and delivery of 
the hardware vhich they select. The initial contract will request the design, 
production, delivery, test, and evaluation of four IMPs. The initial instal- 
lations will be at Stanford Research Institute; U.C. , Santa Barbara; UCLA; 
and the University of Utah. 

The development of this distributed communication system will not only 
provide the communications capability required for the ARPA computer 
research facilities, but will also be a unique prototype of future communi- 
cation systems. Additionally, this network will provide an opportunity to 
demonstrate a form of communications organization recommended in a 
distributed digital network study by the RAND Corporation. 

Administrative Considerations 

The $563 K should provide sufficient funds for the IMP design, the purchase 
of four IMPs and their Installation at the initial nodes. A small network 
which will be created between these four nodes will be used mainly to eval- 
uate the performance of the store and forward communication system. If 
the basic design proves satisfactory, the extension of the network to include 
additional nodes will be considered. Fiscal 1969 funds have been programmed 
for this purpose. 



Transfer Plan 



It i» anticipated that the communication system being developed will be 
attractive to the common carriers aa a potential data service. After four 
nodes of the network can be demonstrated, a common carrier will be asked 
to make an economic evaluation addressing the desirability of offering ouch 
communications as a service. When the entire net is established and operat- 
ing smoothly, the carrier may be requested to manage the net, thus directly 
providing digital message transmission as a tariffed service. This will be 
particularly desirable when the computer network is sufficiently developed 
to include more research centers such as the NSF supported activities. 

Reporting Requirements 

Quarterly progress reports, and final reports covering entire design and 
evaluation at the end of the initial contract. 

Contractor Selection 

To be selected through competitive evaluation by a panel of ARO- Durham 
and ARPA personnel. 

Agent and Level of Support 

ARO-Durham personnel have been involved In the preparation of the speci- 
fication. Technical support will be requested of ARO-Durham; however, 
the project responsibilities should remain with ARPA. 



Lawrence G. Roberts 
Special Assistant for 
Information Sciences 



2 




ADVANCED RESEARCH PROJECTS AGENCY 



ARPA Order No. 1137 
Program Code No. 8D30 
Program Element No. 6. 15.45. OLD 
Industrial Priority Rating: DO 

December 6, 1967 Date 

TO: Commanding Officer 

U. S. Army Research Office (Durham) 
Box CM, Duke Station 
Durham, North Carolina 27706 

1. You are requested to initiate a four-month contract with Stanford 
Research Institute for a study related to the design and specification of 
a computer network. The work should be in accordance with the con- 
tractor's proposal No. ESU 67-92, "A Study of Computer Network De- 
sign Parameters", dated November 7, 1967, with work statement as 
follows: 

a. The contractor will study the effects of selected network tasks 
upon Interface Message Processors (IMP'e) and the communication 
facilities serving a highly responsive network of computers. Among 
the tasks to be studied are: 

(1) The coding of the information exchanged between the IMP'S 
(e.g., USACSIIvs. non-USACSII, transparent binary trans- 
mission) 

(2) Acknowledgement procedures (e.g., message block for- 
mation, restraint of message flow) 

(3) Operational procedures (e.g., user access validation and 
control, recovery from abnormal conditions) 

b. The effects of alternative design choices will be characterized 
in terms of IMP computational capacity, storage capacity, special 
hardware requirements, and loading of the communication facilities. 



c. In carrying out this study, the contractor will communicate with 
other ARPA contractors who are potential participants in such a 
network. 



ARPA Order No. 1137 



2. The study should commence as soon as possible, not later than 
January 1, 1968, The total price is estimated to be $19, 586; an 
additional amount of $214 is provided for ARO-D expenses in connection 
with monitoring this contract. 

3. This Order makes available $19,800 under appropriation and 
account symbol "97X0400. 1301 Research, Development, Test and 
Evaluation, Defense Agencies", for obligation by ARO-D on behalf 

of the Advanced Research Projects Agency, only for purposes necessary 
to accomplish the work specified herein. These funds are immediately 
available for direct obligation. The funds made available herein are 
not for the construction of facilities. 

4. A final technical report should be prepared and submitted in 
accordance with the instructions set forth in the attachment to our 
memorandum dated September 13, 1966, subject: "ARPA Orders - 
General Requirements. " 

5. It is requested that two copies of each contract or contract modi- 
fication awarded as a result of this Order be submitted to the Director, 
ARPA. In transmitting such documents, specific reference should be 
made to ARPA Order No. 1137. 

6. The General Requirements as stated in the attachment to the 
ARPA memorandum of September 13, 1966, are included in this 
Order by reference. 




E. Rechtin 



Director 



Copy to: 

Secretary of the Army 
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ADVANCED RESEARCH PROJECTS AGENCY 
Washington, D. C. 20301 



September 18, 1969 



MEMORANDUM FOR THE DIRECTOR, PROGRAM MANAGEMENT 

SUBJECT: Initiation of a Contract with Raytheon Corporation to Study 
"User Syitem Interaction via the Network" 



Please initiate action to obtain a contract with Raytheon Corporation to 
study "User System Interaction via the Network. 11 The program is for 
12 months at a total cost of $75, 61 1. 

Objective ' 

The objective of the proposed program is to determine Host to Host 
protocol procedures to: (1) reduce the number of special conventions 
that a network user must know, and (2) reduce the number of special 
programs required in order to transmit data from one computer to 
another. 

Background 

Standardized conventions and formats would, in many cases, improve 
the effectiveness of the network. In many other cases standards would 
require undue reprogramming and hinder technological progress. In 
order to examine all the conflicting desires of the research groups of 
each node and evaluate the pros and cons of potential standards, an 
independent party is required; one who is technically qualified to select 
the important issues, digest the evidence', and make recommendations 
to ARPA. Currently there is a Network Working Group with members 
from each early network node which is deciding the initial protocol and 
conventions. However, a committee cannot be expected to investigate 
and solve the more difficult, longer range problems, particularly when 
the best solution may require considerable effort for some of the members. 

Raytheon has evidenced considerable understanding and interest in these 
issueB and proposes to have Thomas O'Sullivan attack the problem. Thi's^ 
provides ARPA with an unbiased source of recommendations and will 
insure that sufficient effort is spent investigating and discussing the impor- 
tant issues. Besides being a respected computer scientist, Thomas 



) 



O'Sullivan is a noted behavioral scientist and will be able to address 
both the computer system questions and the human factors involved. 
In addition, he will provide a unique orientation to the group toward 
the problems of the Behavioral Science Data Centers which will eventually 
be part of the ARPA Network. The conventions associated with data 
sharing, the principal interest of the Behavioral Science projects, are 
particularly important to the long range success of the network. Due 
to this direct involvement with and support for these data centers, one- 
third of the Raytheon contract costs will be supported by the Behavioral 
Science Office. 

Rationale 

ARPA Program Plan 723 established the need and the impact of solving • 
the problems involved in computer networks. This program plays an 
important role in the solution of those, problems. 

Statement of Work 

Review command languages and eyfltem resources available to 
Network users. 

Gain an intimate understanding of command language, user 
operating procedures and available user resources through 
direct on-line use. 

Postulate specific examples of various operating modes of 
^different types of network users and define operating procedures 
to handle these modes of operation. 

Define a generalized ideal system to handle interhost operations, 
incorporating the defined procedures, showing how these opera- 
tions ought to be handled in the network. 

Prepare a report describing the defined system, arguing why 
it ought to be that way, and presenting both its merits and 
weaknesses in relation both to user operation and the system 
, support required to provide it. 

Administrative 

IPT's share is $50,611 and this should be token from Line Item D60200 
for FY 70. Behavioral's share is $25, 000 and these FY 70 funds should 
be taken from Line Item C20500. 
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The agent should be DSS-W because close interaction with IPT is 
required and a second technical monitor is unnecessary. Quarterly 
Management Reports and a Semi-Annual and Final Technical Report 
are desired. .. (i • 



Davis B. Bobrow Liwrence C. Roberts 

Acting Director Acting Director for 

Behavioral Sciences Information Processing Techniques 
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I IKTKOIIUCTIO:; 



The Network Information Center (KIC) is a set of servicss to be 
offered by the Augmented Human Intellect Research Center (AHIEC) of the 
Stanford Research Institute ( SRI ) to the users of the AR?A Computer 

User access to the KIC vill be primarily through the network, but 
alternate means such es phone calls, letters, etc., will also be used 
(at least initially). 

A major goal of the KIC is to try to satisfy those information " 
needs upon which the success of the "network experiment" vill be most 
dependent. The :iIC, then, is concerned with supplying information .and 
documentation services — uo contrasted tc ctner possible cervices such 

II NEEDS 



User needs of concern to the ?iIC are &s follows: 
(l) Creation of Documents 

and fo'r their ow r . use. After a document hss been created the user may 
vish to inspect ar.d/cr modify it. 

(2) Inspection of Documents 

Users will need to examine (i.e. read) documents to various depths. 
Such an examination may be a prelude to subsequent modification actions 
or other retrieval actions. 

(3) Modification of Documents 

Users will need to modify documents of their own creation, vhether 
to correct errors, add, delete, change, or merge. They vill also desire 
to modify documents created by others. 

(It) Searching for Documents 

The user will need to be able to scan collections of documents to 
search for items relevant to his work at a given moment. If a search is 
successful the user will desire to inspect and/or retrieve documents 
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(5) Retrieval of Documents 

When a user has strong interest in a document, set of documents, or 
sections of documents, he vill need to have a copy of the material for 
hinself. The retrieval of such information Kay result in copies in 
various forns — e.g. hardcopy (paper, microfilm) or softcopy (computer 



III SERVICES 



To satisfy these needs the lilC is expected to provide the following 

(l) Access to NIC Services 

This vill be initially provided via the network and via "dialup" 
Dataphone lines for typewriters and low-speed CRT terminals. Later 
access vill he provided via the network for high-perfornance CRT 
terminals. 

(2) A Repository for a Collection of Documents 

This collection vill consist of documents contributed by network 
users or collected by the staff of the iilC. . Eler.ents of the collection 
will include research reports, user's guides, systen and program 
descriptions, actual code, and papers of general user interest. The 
collection vill be kept in various versions: 

In hardcopy, as microfilm and paper masters held at the NIC. 
Replicas would be routinely distributed to each network site 
and other selected organizations for the users. 

Special nicrofiln replicas of selected portions of the 
nicrofiln masters or the softcopy would be provided in 
nicrofilTi fora upon request. 

A catalog will be one of the elements in the collection. It vill 
list all material in the collection, whether it exists as softcopy, 
hardcopy, or any combination. 
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(3) A Docunentation-Aid System 

The systen, oriented to typewriters and CRTs, vill incorporate text 
editing and text restructuring facilities similar to those now available 
in the AHIF.C On Line Systea (IILS). 

The hierarchical structure, basic to the concept of the IILS, will 
be available for use in all documents held by the IIIC. (It may, of 
course.be used simply as a list of paragraphs, headings, etc.) The 
docur.entation-aid system vill assist the user in g-nerating and using 
documents that exploit the possibilities of this structure. 

" A transcription service will be available at the IIIC to transcribe 
hardcopy documents into a softcopy version to be held in the IIIC. This 

during the initial phase of the network) without unduly burdening the 
user. It will provide a transition interval while users become 
acquainted with the IILS document structure format. Ultimately, it is 
assu.-r.ed that documents will be originally written with the use of 
computer aids — either on the user's computer or with NIC's 

(it) A Query and Search System 

This system will be applicable to softcopy and hardcopy versions of 
the collection. By means of the "content analyzer" (a feature of the 
present IILS) the user will able to construct content specifications for 
searching the IIIC collection. 

By neans of links between documents and within any one document 
(another feature of the present KLS) the user will be able to follow 
predetermined "trails" through the IIIC collection. 

Plans are being made to develop a IIIC catalog, encompassing the 
softcopy and hardcopy (microfilm) versions of the collection. 

(5) A Retrieval and Output System 

This system will have online, offline, softcopy, and hardcopy 
(microfilm) applications. 



The user -will be able to request a "copy" of the document for his 
use. This may be a softcopy for use through IIIC aids, or for use at his 
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The user may also r.ake special requests for hardcopy versions 
either on microfilm or on paper, both produced at the NIC. If he 
obtains a copy of the file at his machine he can, of course, produce his 
own hardcopy version. 

It is expected that the user will typically desire selected "views" 
of the document, rather than the entire document itself. A view can be 

(number of lines of each statement), and section or sections of the file 
or files. 

The view will be chosen by the user and will depend upon the depth 
vith which hs wishes to examine the document f.nd the type of terminal at 
his disposal. A typewriter user will desire smaller volumes of naterial 
than will the CRT user, because of the slow speed of the terminal; the 
range of possible views will reflect this. 

IV IlilTIAL Pl-AHS 



The initial plan covers the period frcn the present to December 
1969. During this interval the network will be in its developmental 
stage and will be unavailable for general use. The parties concerned 
vith this development will be ARPA, B3!/ (the network contractor), and 
the four initial sites (UTAH, UCSB, UCLA, SRI), These parties are the 
prir.ary users to be served during this tire with the emerging NIC 
services, iilC's specific service features are being oriented toward the 
needs of these users. Users at the other 15 sites are expected to use 
the lilC to a lesser degree during this period, but will becoir.e 
increasingly active during the latter part of 1969 and through 1970. 

Initial Services 

The focus of the KIC will be upon the development of its basic 
collection of documents, a Typewriter-Oriented Documentation-Aid System 
(TODAS), and a early version of the on-line search and retrieval 
process. 

Inforaation in the initial collection is being oriented to 
docunents pertaining to the network development, and to descriptions of 
systems and subystens to be available at the initial sites. This 
information consists of program documentation, systea descriptions, user 
manuals, protocols and procedures, and status reports. 
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A preliminary version of the Typewriter Oriented Document Aid 
System (TODAS), is now in use by the transcription service, operating in 
the off-line mode only. 

Quite early, about the 2nd quarter of 1969, the collection will be 
made available to the users in microfilm form. At that tine a NIC 
system, called Graphics-Oriented Document Output System (GODOS) will 
enable conputer-held information at the I/IC %p be recorded onto 
microfilm via a CRT. 

During the third quarter of 1969 an on-line version of TODAS should 
be implemented to permit users, with Teletype machines on the dialup 
telephone network to call into the HIC and execute a limited search 

During the last quarter of 1969 the on-line version of TODAS with 
text-manipulation capabilities should be available. 

Present Collection 

The present HIC collection contains (in softcopy form) all or 
portions of the following documents: 

Half-Tone Perspective Drawings by Computer. 

C. Wylie, G. Romney, D. C. Evans, A. Erdahl, (UTAH) 

lU November 67, Revised 12 February 68. 
A FORTRAN V Interactive Graphical System. 

A. C. Reed, D. E. Dallin, S. T. Bennion, (UTAH) 

3 April 68. 
GS - Graphics System 

t. Copeland and C. S. Carr (UTAH) 

November 15, 1967, 
Illiac IV — Systems Characteristics and Programming Manual 

Burroughs Corporation (UI) 

1 March 1963, Change 1, 12 June 1968 
Procedures and Standards For Inter-computer Communications 
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NIC NEWSLETTER 
16 January 1969 

A. K. Bhushan and R. H. Stotz (MIT) 

Reprinted from AFIPS Conference Proceedings, Volume 32, 1968 

Specifications of Interface Message Processors for the ARPA 
Computer Network (Statement of Work Annex "b") 

Advanced Research Projects Agency (ARPA) 

July 29 1968 
U.C.S.B. On-Line System Manual 

University of California, Santa Barbara (UCSB) 

October 1, I967 
A Study of Computer Network Design Parameters 

E. B. Shapiro, (SRI) 

December I968 
• HIC Newsletter 

NIC Staff (SRI) 

Jan. 16, 1969 
Network Newsletter 

NIC Staff (SRI) 

Jan. 6, I969 



6 



Fiqur9 I: INFORMATION FLOW 



IN AND .OUT OF THE NIC 



PAPER 1 MAIL, 
TAPE 



MICRO- 
FILM 



ADVANCED RESEARCH PROJECTS AGENCY 
Washington, D.C. 20301 

Program Plan No. 723 
Date : 3 June 1968 

Program Title: RESOURCE SHARING COMPUTER NETWORKS 

Type of Contractor: To be selected from 4 - Industry (Profit) 

Project from which Funded: Information Processing Techniques (8D30) 

Prepared by: . - ■ O^-' .<L, 

Program Manager 

Concurred in: lE^/r^ .. 

Robert W. Taylor, J3irector for 
Information Processing Techniques 

Approved by: 

Director, ARPA 

Date: 

Type of Work: B (Applied Research) 
Field of Work: 77 (Computer Sciences) 



ADVANCED RESEARCH PROJECTS AGENCY 
Washington, D.C. 2030! 



Program Plan No. 723 
Date: 3 June 1968 



RESOURCE SHARING COMPUTER NETWORKS 

A. Objective of the Program. 

The objective of this program is twofold: (i) To develop techniques 

very broad class of interactions are possible, and (2) To improve and 
increase computer research productivity through resource sharing. By 
establishing a network tying IPT's research centers '.ogcther, both goals 
are achieved. In fact, the most efficient way to develop the techniques 
needed for an effective network is by involving the research talent at these 
centers in prototype activity. 

hundreds of individual users to' share hardware and software resources 
■with one another, networks connecting dozens of such systems will permit 
resource sharing between thousands of users. Each system, by virtue 
of being time-shared, can offer any of its services to another computer 
system on demand. The most important criterion for the type of network 
interconnection desired is 1 that any user or program on any of the net- 
worked computers can utilize any program or subsystem available on any 
other computer without having to modify the remote program. 

B. Technical Need and Background of the Program . 
1 . Scientific Environment . 

trading of programs between those machines which are sufficiently similar 
to allow this, and there is technical communication through publications 
of technical meetings describing techniques developed. However, since 
the computer field is growing at such a rapid rate, a more immediate 
mechanism must be developed if there is to be significant cross -fertiliza - 
tion in sharing between these many centers. Although the same problem 
exists in many technological areas, the solution is most easily found and 
implemented by the computer community. If a sufficiently reliable and 




More recently, experiments have been carried out between Lincoln 
Laboratory and System Development Corporation to test the feasibility 



In December 1967, a small contract (AO 1137) was initiated with 
Stanford Research Institute for the development of specifications for 
the necessary communications system. This effort has resulted in 
sufficiently detailed documentation to allow a request for bids on Inter- 
face Message Processors (MPs). SRI will also provide continuing 
assistance to the initial participants in the network. 

2. Network Information Center 

In order for people to utilize the envisioned computer network 
effectively, it will be necessary to provide extremely good documentation 
on what programs and files are available throughout the net. This 

It should be possible 'for him to add new program descriptions, edit 

searches and affix comments to program descriptions which he has used. 
To achieve this goal, Stanford Research Institute has been tasked with 
developing such a facility. This is an extension of the capability already 
achieved at SRI and is in progress in order that it may become available 
concurrently with the network. 

Multi-point, fast response, high capacity, reliable communica- 
tions are required for an interactive computer network. The traffic 
between nodes is expected to consist mainly of short digital messages 
with a wide dispersal of destinations. Initially, message length will 

length of 20 characters. Since a cross country 50 kb communication 
line has a delay equivalent to 150 characters, messages must be con- 
tinuously multiplexed into each line in order to maintain reasonable 
efficiency. Since the dispersion of destinations is large, messages 
with different origins and destinations must be concentrated into the 
same line. This can only be achieved with a store and forward system. 

Message delay for on-line, interactive work should be well below 
one second (origin to destination). This cannot be achieved with voice 
grade communication lines in a store and forward system. However, 
with 50 kilobit communication lines, the required response speed can 
be attained. The additional capabity obtained with 50 kb lines is also 
important, but is not the prime factor dictating the choice of these lines. 

After considering the trade-offs associated with the communications 
subsystem, it was decided to design and build a store and forward net 
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in three forms: (1) Dissemination of techniques and experimental 
results through the open scientific and technical literature, (2) Through 
the common carriers or other commercial organizations concerned 
with data transfer and dissemination, and (3) Through the military 
command and control centers for which the National Military Command 
System Support Center in the Pentagon serves as the focal point. 

1. Publication of Results . 



through conferences and the appropriate literature is a slow but 



puter organization serving the Joint Chiefs of Staff and operates unde 
the management of the Defense Communications Agency, its comput< 
capability serves also as the fountain!. ead for military command and 
control centers around the world. IPT has paid for the development 
of a prototype time-sharing system to be tested in the NMCSSC over 
the next 12 months. As a result of these test findings, it is expected 
that the NMCSSC will move away from conventional batch processing 
and into the computer technology created by ARPA and its contractor 
As it does so, other military centers affiliated with it will follow, e. 
CINCPAC, CINCEUR and MACV. Such a collection of affiliated milit 
centers using computer technology represented by ADEPT -TDMS pro 
vides a natural recepient for an interactive computer network. Trans 
will be facilitated by SDC's (creator of ADEPT -TDMS) participation i 
the ARPA experimental network. The ability of military command 
systems to be able to interactively call upon one another through a 

bility and common data base interests. 



9 



ADVANCED RESEARCH PROJECTS AGENCY 
Washington, D. C. 20301 

Job* 21. 1968 

••» g* i -- •••-•„•" 
' MEMORXIuSfeM FOR THE DIRECTOR, PROGRAM MANAGEMENT 

-. «c '• 

~SUBJECT: (t jhteractlve Computer Network Communication System .< 
•'' * ' * .. . ,. ■ ^ v „ ... 

The purpose of tola memorandum la to request an ARPA order be written 
to ARO-Durham for $563 K to Initiate a contract for the dealgn, construe - 
tlon, installation, teat and maintenance of interface mesaage processors 
(IMPs) to form a communication system to support the ARPA network 
activities. The contractor la to be selected by competition between 
aelected bidders. 

APP No. 723, submitted with this memorandum, describee the require- 
ments for a network and the need for a distributed store and forward com- 
munications ayatem. A detailed specification has been written to permit 
potential contractor a to bid on providing the IMPa. Thla bid will be for 
total ayatem responsibility. Blddera who are not computer manufacturers 
must therefore negotiate with a manufacturer on the price and delivery of 
the hardware which they aelect. The Initial contract will request the dealgn, 
production, delivery, test, and evaluation of four IMPa. The initial instal- 
lations will be at Stanford Research Institute; U.C. . Santa Barbara; UCLA; 
and the University of Utah. 

The development of this distributed communication system will not only 
provide the communications capability required for the ARPA computer 
research facilities, but will also be a unique prototype of future communi- 
cation systems. Additionally, this network will provide an opportunity to 
demonstrate a farm of communications organisation recommended la a 
eUstrlbuted digital network study by *na RAND Corporation. _ x _ . 

•- ■ «••* - ■■ ■■■ ■ - ■ . '. 

.Administrative Considerations :• *• \ 

. The $56 J J^Vhould provide sufficient finds for the IMP design, the purchase 
of four IMPa and their InatalUtloe at the initial aodee. A email network 
which will be created between these four nodes will be used mainly to eval- 
uate the performance of the etore and forward communication system. If 
the basic design proves satisfactory, the extension of the network to include 
additional nodes will be considered. Fiscal 1969 funds have been programmed 
for this purpose. 



Transfer Plan 



. A. 

It la anticipated that the communication a rate m being developed will be 
"attractive to tne common curlin aa a potential data aarvicc. After four 
modes of the network can be demonstrated, a common carrier will be aaked 
to make an economic evaluation addressing the desirability of offering auch 
^communlcatlona ai a service. Whan the entire net la established iknd operat- 
• -teg smoothly, the carrier may be re quae ted to manage the net, thus directly 
providing digital naeeaage transmission ai a tariffed ear vice. Thia will be 
particularly desirable when the computer network la aufflciently developed 
to include more research centers auch as the NSF supported activities. 

Reporting Requirements 

Quarterly progreas reports, and final reports covering entire design and 
evaluation at the end oi the initial contract. 

Contractor Selection 

To be aelected through competitive evaluation by a panel of ARO- Durham 
and ARPA personnel. 

Agent and Level of Support 

ARO -Durham personnel have been Involved in the preparation of the speci- 
fication. Technical support will be requested of ARO-Durham; however, 
the project responsibilities should remain with ARPA. 



•. -|»awrence C. Roberts 
* Special Assistant for 

^' Information Sciences 

. Saeloeure^ ■ . ■■ - 

.'. APP 72S- v ". * * 
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r. SUPPLY SERVICE- WASHINGTON 
D 245, The Pentagon 
gton, D. C. 20310 



Bolt, Beranek, and 
; 50 Moulton Street 
Cambridge, Massachi 



DCASR, Bosti 



»"' !S2 202A 
NONE 



3= IW to 



10 U.S.C. 2304(a) (11) 



WHEREAS, the Contractor and the Government entered into Contract No. 
HC15 69 C 0179 under date of 2 January 1969 which, together with any and i 
endments, changes, modifications and supplements thereto, is hereinafter i 

WHEREAS, the parties hereto have mutually agreed to Che estimated cost 

xed fee for the changes arising under Modification P00015 (Change Order), 

tion M, Revision 1, and Option N, Revision 2, of Contractor's proposal P7: 
Y-1B, and 

WHEREAS, the parties hereto do mutually agree to extend the contract; 

NOW, THEREFORE, in consideration of <:he mutual covenants and agreement: 
rein contained and for other good and valuable consideration, the parties 
reto do mutually agree to amend said contract as follows: 

The Contract is hereby revised and restated in its entirety as follows 



1NTRACT NO. DAHC15 69 C 0179 MODIFICATION NO. P00019 

'It, Beranek, and Newman, Inc. 
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SCTION B. CONTRACT FORM AND REPRESENTATIONS, CERTIFICATIONS AND OTHER 
STATEMENTS OF OFFEROR . 

1. DISCLOSURE STATEMENT -CO ST ACCOUNTING PRACTICES AND CERTIFICATION. 

Any contract in excess of $100,000 resulting from this solicitation, 
cept when the price negotiated is based on: (1) established catalog or 
■rket prices of commercial items sold in substantial quantities to the 
neral public, or (2) prices set by law or regulation, shall be subject 
" the requirements of the Cost Accounting Standards Board. Any offeror 
bmitting a proposal, which, if accepted, will result in a contract sub- 
ct to the requirements of the Cost Accounting Standards Board must, as 
condition of contracting, submit a Disclosure Statement as required by 
gulation of the Board. The Disclosure Statement must be submitted as a 
rt of the offeror's proposal under this solicitation (see (1) below) unless 
.) the offeror, together with all divisions, subsidiaries, and affiliates 
der common control, did not receive net awards of negotiated defense prime 
ntracts during the period 1 July 1970 through 30 June 1971 totaling more 
an $30,000,000 (see (2) below), (ii) the offeror has already submitted a 
.sclosure Statement disclosing the practices used in connection with the 
icing of this proposal (see (3) below), or (iii) post-award submission has 
en authorized by the Contracting Officer. CAUTION: A practice disclosed 
a Disclosure Statement shall not, by virtue of such disclosure, be deemed 
be a proper, approved, or agreed to practice for pricing proposals or 
cumulating and reporting contract performance cost data. 

eck the appropriate box below: 

) 1 • CERTIFICATE OF CONCURRENT SUBMISSION 

OF DISCLOSURE S TATEHENT ( S ) 

The offeror hereby certifies that he has submitted, as a part of his 
oposal under this solicitation, cipies of the Disclosure Statement(s) as 
Hows: (i) original and one copy to the cognizant Administrative Contract- 
g Officer (ACO) (see DoD Directory of Contract Administration Components 
)oD 4105. 59H); (ii) one copy to the cognizant contract auditor; and (iii) 
e copy to the Cost Accounting Standards Board, 441 G Street, N. W. , 
shington, D. C. 20548. 

Date of Name(s) and Address(es) of Cognizant 
sclosure Statement(s) ACO(s) Where Filed 

The offeror further certifies that practices used in estimating costs 
. pricing this proposal are consis.tent with the cost accounting practices 
.sclosed in the Disclosure S tatement (s) . 

) 2. CERTIFICATE OF MONETARY EXEMPTION 



The offeror hereby certifies that, together with all divisions, sub- 
diaries, and affiliates under common control, he did not receive net awards 
negotiated national defense prime contracts during 1 July 1970 through 
June 1971 totaling more than $30,000,000. 
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isclosure Statement (s) 

The offeror further certifies that practices used in estimating costs 
n pricing this proposal are consistent with the cost accounting practices 
isclosed in the Disclosure Statement (s ) . 

ECTION E. SUPPLIES/SERVICES AND PRICES ■ 

tern Supplies or Services Total Estimated Cost 

001 Research and development for the Defense 

Advanced Research Projects Agency Computer 
Network 

Estimated Cost $7,034,987.00 
Fixed Fee 601,953.00 
Total Cost Plus Fixed Fee $7,636,940.00 
ACRN - 1A,B,C,D,E,F,G,H,I,J,K,L,M,N,P,Q,R. 



Estimated Cost $ 337,835.00 

Fixed Fee 28,919 .00 

Total Cost Plus Fixed Fee $ 366,754.00 
ACRN: 2A, B. 
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ECTION F . DESCRI TP ION /SPECIF I CATIONS . 



-1 . Scope of Work. 

a. Unless otherwise provided herein, the Contractor with due diligenci 
tail furnish all necessary qualified personnel, material and equipment, 
inaging and directing the same, to complete the work described in Annex "A" 
id revisions thereto entitled "Statement of Work: Specifications of Inter- 
ice Message Processors for the ARP A Computer Network" and Exhibits 1 and 2 
ireof, in accordance with his proposals listed in Annex "D", Contractor's 
•oposals, which listed proposals by this reference, are specifically made a 
irt of this contract and are on file in the office of the Contracting Offio 

b. As a part of the work to be performed the Contractor shall furnish 
ports for Items 0001 and 0002 as follows: 

0001 - Quarterly Management Reports 
Milestone Reports 
Quarterly Technical Reports 



ants for 

0002 - Quarterly Management Reports. 
Final Technical Report 

jports for Item 0002 shall be rendered in accordance with Exhibit 0002, 

'ports Requirements and Delivery Schedule for DCA IMP Network, which by 

lis reference is specifically made a part of the contract. 

c. The reports required by contract and the deliverable data set fc 
.sewhere in the contract are data to be delivered in accordance with the 

i.ause entitled "Rights in Technical Data" of the General Provisions. 

•1CTI0N H. DELIVERY SCHEDULE . 



0001 - The funded period of performance for this item ends 18 June 
J74. Individual deliverables shall je made in accordance with Exhibit 1, 
^.livery Schedule for the ARP A Co^putsr Network. 

0002 - The funded period of performance for this item ends 14 March 
!74. Individual deliverables shall >e made in accordance with Exhibit 0002, 
sports Requirements and Delivery Schedule for DCA Computer Network. 
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ECIION J. SPECIAL PROVISIONS . 

-1. Project Officer . The Contracting Officer may designate Contracting 
fficer' Technical Representatives to: 

a. Act as Project Officer under this contract. the Project Officer will 
eceive for the Government, reports and other materials called for in this con- 
tact and will represent the Contracting Officer in the technical phases of the 
ork. The Project Officer is not authorized to change any of the terms and 
onditions of this contract. Changes in the scope of work will be made only by 
he Contracting Officer by properly signed written modifications to the contrac 
uch representatives as may be appointed will be specifically designated in a 
etter from the Contracting Officer to the Contractor. 

-2. Allowable Costs . It is understood and agreed that, subject to the pro- 
isions of the clause entitled "Allowable Cost, Fixed Fee and Payment" of the 
eneral Provisions the following shall be considered as allowable items of cost 
nder the contract when incurred or paid by t'ue Contractor and when necessary 

oes not preclude the allowance of other costs allowable under Armed Services 
rocurement Regulation, Section XV): 

a. Salaries and Mages . Expenditures by the Contractor for salaries and 
ages of his personnel and borrowed personnel directly engaged in the perform- 
nce of work hereunder; and properly allocable to this contract including 
'ederal and State taxes paid by the Contractor and properly allocable to such 
alaries and wages. 

b. Travel and Subsistence . Travel and subsistence expenses shall be 
aid in accordance with the Contractor's approved travel policy. The differenc 
,n cost between first-class air accommodations and less than first-class air 
.ccommodations is unallowable except when less than first-class accommodations 
.re not reasonably available to meet mission requirements. Reasonableness 
hall be ascertained by a review of all facts pertaining to the specific costs 
y the Contracting Officer. Should transportation and subsistence expenses be 
ncurred concurrently in connection with the performance of more than one con- 
tact, such expenditures shall be allocated on an equitable basis to the con- 
tacts involved, such allocation to ba based on a review of all pertinent facts 
:oncerned with the particular trip. 

c. Materials and Supplies . Expenditures by the Contractor for such 
.aterials, supplies, apparatus, equipnent, and other articles (including rental 
f apparatus and equipment) properly allocable to performance of the work here- 

d. Indirect Costs . Except as to the incurrence of subcontract costs 
■ith Honeywell Incorporated and Telecomp, indirect costs shall be reimbursed 
n an actual cost basis in accordance with Section XV, of the Armed Services 
rocurement Regulation. Subject to final es t iib 1 ishnen t by cognizant Govern- 
ient auditors of actual indirect costs incurred, such costs shall be reimburse! 
n a provisional basis through means of a billing rate acceptable to the 
lontracting Officer. In connection with the incurrence of subcontract costs 
;ith Honeywell, Inc., the indirect costs incurred by the Contractor shall not 
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'.ETION L. GENERAL PROVISIONS . 

e Armed Services Procurement Regulati 
corporated in this contract by refere 
if set forth in full. The full text 
69 Edition of the Armed Services Proc 
pplicable Defense Procurement Circ 



of each clause : 
irement Regulatic 
ilars through No. 



72. 

AUSE TITLE AND DATE 

finitions (62 Feb) 
.mitation of Cost (66 Oct) 

lowable Cost, Fixed Fee and Payment (72 Jan) 

andards of Work (59 Feb) 

spection (59 Feb) 

signment of Claims (62 Feb) 

amination of Records by Comptroller General (71 Mar) 
bcontracts (72 Apr) 

ilization of Small Business Concerns (59 Jun) 

rmination (71 Nov) 

sputes (58 Jan) 

negotiation (59 Oct) 

y American Act (64 Oct) 

nvict Labor (49 Mar) 

lsh-Kealey Public Contracts Act (58 Jan) 

ntract Work Hours and Safety Standards Act-Overtime 

Compensation (69 Nov) 
ual Opportunity (71 Apr) 
ficials Not to Benefit (49 Jul) 
venant Against Contingent Fees (58 Jan) 
thorization and Consent (61 Jan) 

tice and Assistance Regarding Patent and Copyright 

Infringement (65 Jan) 
tent Rights (License) (69 Dec) 
ghts in Technical Data (72 Apr) 

vernment Property (Cost Reimbursement) (70 Sep) 
surance-Liability to Third Persons (66 Dec) 
ilization of Labor Surplus Area Concerns (70 Jun) 
yment for Overtime 1 remiums (67 Jun) (Insert "0" in bli 
mpetition in Subcontracting (62 Apr) 
dlt by Department of Defense (71 Apr) 
anges (67 Apr) 

chnical Data - Withholding of Payment (72 Apr) 
bcontractor Cost and Pricing Data (70 Jan) 
ilization of Minority Business Enterprises (71 Nov) 
cusable Delays (69 Aug) 
atuities (52 Mar) 

mitation on Withholding of Payments (59 Feb) 
terest (72 May) 

sting of Employment Openings for Veterans (71 Nov) 



below are hereby 
force and effect 
s as published in ti 
n, through Revision 
107, dated 11 Decen 



ASPR REFERENCE 



7-103.1 
7-' 



a) 

7-203. 4(a) 
7-402.4 
7-402 . 5 (b) 
7-103. 8 
7-104.15 
7-402 .8(a) 
7-104. 14(a) 
7-203.10 
7-103. 12(a) 
7-103. 13(a) 
7-104 . 3 
7-104.17 
7-103.17 

7-103.16 
7-103.18 
7-103.19 
7-103.20 
7-302.21 

7-103.23 
7-302. 23(b) 
7-104. 9(a) 
7-203.21 
7-203.22 
7-104. 20(a) 
7-203.27 
7-104.40 
7-104. 21(a) 
7-104.1 
7-204. 9(b) 
7-104. 42(a) 
7-104. 36(a) 
7-203.11 
7-104 .16 
7-403. 12 (a) 



7-: 



.39 



7-103.27 
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LAUSE TITLE AND DATE 



ASPR REFERENCE 



Precedence (65 Aug) 7-104 

k Order (71 Apr) 7-105. 3(c) as modified by 7-205 

of Work (60 Jul) 7-404 

Pre-Award Clearance of Subcontracts (71 Oct) 7-104 



f Patent Applications (69 Dec) 
d Risk of Loss (68 Jun) 

duction for Defective Cost or Pricing Data (70 Jan) 
es, Allocations and Allotments (71 Apr) 

Inspection and Receiving Report (69 Dec) 
ounting Standards (72 Jul) 



7-104 
7-103 
7-104 
7-104 
7-104, 
7-104, 
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JCTION M. LIST OF DOCUMENTS, EXHIBITS AND ATTACHMENTS . 

•1. Annex "A", Statement of Work; Specifications of Interface Message 
Processors for the AR? A Computer Network. 

-2. Annex "B", Requirements for ARPA Sponsored Contracts. 

-3. Annex "C", Accounting and Appropriation Data. 

-4. Annex "D", Contractor's Proposals. , 

-5. Exhibit 1, Delivery Schedule for Item 0001. 

>6. Exhibit 2, Delivery Schedule and Reporting Requirements for Item 0002. 



Sponsoring Agsncy: 



Advanced Kese.arch Projects Agency (ARPA) 
HaEliini-tCD, I). C. 20301 

SPECIFICATION 
INTERFACE t-SESACE 
FOR THE Ari'A CCIi'l' 
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B. Functional Description of the Network 



For the purpose of delineating areas of responsibility and 
specifying design requirements the network is subdivided into the U 
ing components: 

1. The USER SUBNET 

a. The HOST systems: 

independent of the formation or construction of the 



individually designed and ir- ■ ler.snr.ed for his own 
convenience in attaching hi^ilf to the network. 

The contractors own hardware and software 
specifically oriented to his utilisation of some 
other HOST system within the network. 

The COMMUNICATION SUBNET 

a. The CARRIER systems: 

The coiraon corrier facilities available by 

of the network. ? 



The store-and-forward message processors 

The hardware interfaces attaching the message, 
processors to the data sets of the CAKUIER. 

The procedures, hardware and software, for 
message transmission, validation, failure detec- 
tion, recovery, and data gathering. In general, 



sors^whlch maintain at all network sites (hereafter 
called the CARRIER side of the IMP) . 

The hardware interfaces attaching the message 
processors to the local HOST(s) . 

The procedures, hardware and software, for 

and as specif ically°required for the local HOST, 
(hereafter called the HOST side of the IKP) . 

To visulize the operation of the network, consider the following examples 
of expected interactions. 

Example 1. Documentation activities using the S.R.I. HOST system. 

The HOST at Stanford Research Institute will maintain a network 
library of documentation information. So™ ol this information is private 
to S.R.I. , scr.a is available to all network ucers, some is available to 
particular network users. The S.R.I, systems for handling such informa- 
tion on-line is to be :r,ade available to the network users. The on-lir.e 
controls coming from an S.R.I, consols specify precisely the program 
control of the documentation system. Consequently, the outputs generated 
by any console in the^network can be capped into the set of S.R.I, console 

trols of the S.R.I, system, In the other direction, the display output to 
an S.R.I, console umouely specifies the visible results of applying the 
above controls, Ccnso-tuencly, the data strcir.: fro- the ccr.-pu-.^r to ts.e 

similarly display such visible results at the user' site. This would also 
be handled by a ref or:.::ttting program in the users' HOST. 

In general, there is room for many different selections of how and 
where to programmatica Uy connect two HOST sites, the above is only 
intended as an example, We could just is well elect to transport the S.R.I, 
document to the user' HOST and reformat this document to a fov« acceptable 
by the HOST System and then apply HOST display (or line printer) programs 
to the resulting document, 
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Example 2. Network studies using the UCLA HOST system. 



The HOST system at UCLA will include analysis programs for 
studying network performance. The design of the IMPS will include 
facilities for gathering network data when requested and reporting this 

HOST system "to effect the selection of data gathered and to govern its 
analysis of the UCLA HOST system. Or, the aiar may elect to have 
the raw data sent to hin directly for processing by his own programs. 
To avoid conflicts, such e::pe riments will normally be scheduled and 
monitored by the UCLA HOST. 



Example 3. Extended console operation in the network. 

Since many sites have unique facilities, we can exnect rich inter- 
action to accur, as it is only necessary to ijvjoicp ^i;aXKCO:;:~CTICN 

system. From the point of view of the ARPA contractors as users of the 

IKTEKCO:!KECno:; SOtTCARE we should only r.-ed to use the I/O conventions "for 

the details of subnet operation. Specifically, error checking fault 

failures and carrier reality assessment, as required to j-ua.-sr.tae reliable 

Howecer, during the pi.riod of des'ign and construction of the vatuork, the 
user contractors can provide aid to the network contractor as suggested 
in Section IV B below. 




Connection of Host 



to Carrier Facilities 



through. 



C. Functional Description of the IMS. 



The set of I>!PS is to serve as the interface between the set oi 
HOSTS and tha CARRIER network. Each transmit tine HOST looks into 
the network' through its adjacent UT and sees itself connected to the 
receiving HOST (t-hich responds to requests from the transmitting HOST 
after a delay due to IMP and CARRIER congestion is well as its own 
congestion). Each receiving HOST sees the n-;Siorlc through its adjacent 
I HP and responds to incoming data as from a sat of remote terminals 
caking requests. The .letuork sc-»s a set of IMPS providing and accept- 
ing message traffic. Each IH sees the network as a source of messages 
for its receiving HOST, and as a sink for messages fro:n its transmittin 
HOST and from cassayos, using it as a relay I!'?. The V.T , as part of 
its basic function must smooth out severe fluctuations in the message 
traffic by providing temporary message buffering. 



s appropriate, to the 
i KOST(s) . In the execution of 

IKP-I!-? communication protocol « 
, as established by ARJ'A. A ter 



(1) Breaking rressages into packets 

(2) Manages^ t ct message buffers 

(3) Routing of messages 

(4) Generation, analysis, and alteration of formatted 

(5) Coordination of activities with other UTS 

(6) Coordination of activities with its HOST 

(7) Measurement of network parameters and functions 

(8) Detection and disposition of faults 



tins. These chanties may occur as the network changes in size, or 
changes in mode of application, and is subjected to improvements and 
experimentation. It is necessary, then, that the design of the IMP p 

relative case. The program-hardware tradeoffs, the nodularity of the 
elements, the ability to make program changto from remote locations, 
the selection of the source language for the programs are all of cone 

1. Breaking of Messages into Packets 

HOSTS will wish to communicate with messages of longer lc 
than can he reasonably transmitted as a single block due to 
probability of retran'sssission. Thus, a Packet is a fined as 
unit and Message as the inter-HOST unit. A packet will not 



t of Message Buffers 

bufiers will' be 

5 that encounter delays in b 
2 copy of foruart^d data for 



Hitting the flow or looming data from the net and frosi its HOST when 
buffer space is avail, ble, quenching this flew when the space is scarce or 
unavailable. This control (stimulating or qvonchinc) is brought about 

3. Routing of Messages 

For each incoming packet and each IhP-generated packet 
"which is not destined for a particular IMP'S HOST, the IMP chooses the 
next immediate destination by the execution of a routing algorithm. Such 
an algorithm will typically take into account the ultimate dor cination of t 
packet, the connectivity of the network, the loading and condition of the 
"ration links ar.d other IMPS, and the message priority. When 
ting algorithm indicates that a message whould wait for a busy 
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and terminated by control K2ssages ' received roa 
8. Detection and Disposition of Faults 



channels and KOST-IKP cha 



(1) if the signals adhere t 

(2) if the data contained i 



xs specif iea in the 
:ially caused faults 



Upon detection of a fault the IV:? ;:n 
effee- in a nitraer that results in the corrup'.v;. 
of messages, Such isolation may involve the ncg 

Recovery procedures should be used t 
orderly canner, when the fault has been rcttoyec. 

sessapes exchanged be&wan IMPS may report the r 
a faulty IhP or HOST. 



1C 
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The software within the can be functionally separated into two 
categories: (1) the HOST side and, (2), eh a ajtvork side. Since the HOST' 
sLaff can program, the 1:2, it 13 rasorar.ar.dod . .ac physical z^y.ycy proctccio 

thc F 1.0Sl side of the 113? : 

(1) IIT-1103T single channel control 

(2) EuCfers 2nd buffer control 

(3) Kesr.afc to packets and packets; to message conversion 

(4) Packet formatting. 

The contractor shall leave sufficient ir.cnory space for the HOST to add spec 
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(2) Reliability 

(3) Network capacity 

lor the purpose of calculation and evaluation, a si^l 
network is presented, rhe iredcl should allc: tha cons. 
Ms /-dees witho.-.t eithar kncvlnp the ^specirU •iojoiopy 



The cessaj.s dalty is the tics reyjirsd 
ik-skej-p. (single picket n-stsa t ;e) to go fro;n t:..i ari 
with the sending HOST; to the destination UJ (js.; 
receiving UOSX) . It is desired that the averupe 
entire network be triniciized . In particular, a 
should be less than 1/2 second for a fully lauded 



Coci.unications D.'lay 
Full Packet Trar. .miss 
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c. 112? Processing Delay 




The follewinr is a simple iradel of tb.s r.;t*srk d 
topoloRy and data transmission. Several pavi.\;..2t'.;f:i arj s ivo 
determining the da lave encountered by packet.;. 2h.s ,::ri--.ti 
fiven as average; over the nodes and over a ivj.iiir or s«;.-pla 
What is not included ;s the processing tire qtnuivsj?, ;:<sl* 

bidder. ^ 

a. The number of links which a visstpi nust travorse to 
.get froir, one node to another (represented by tnis lecher 01; is 3. 

b. The nunker of links connected to each node (represented 

by k) is 4. 



,cribinj it 
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c. The input rate from the HOST to the IMP is 20 kilobits 

per second. 
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II. Network Contractor Performance 

This contract is for the installation, operation and maintenance 
of a multiple-node network, servising as Che communication facility 
for research and development of data exchange among computers. At 
each node, there will be at least one (1) Interface Message Processor 
(IMP) or Terminal IMP, as given in Exhibits 1 and 2. The Contractor 
shall have full system responsibility including design, development, 
fabrication, installation, test and maintenance of all IMP's in the 
network, including the communication software. The Contractor shall 
provide system documentation in regard to the IMP hardware, the 
communications software, the IMP programming language and the appro- 
priate interfaces between IMP and Host computers and between IMP and 
telephone circuit modems. 
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A. D^aign the CODIFICATION SUBLET cons 

1. I MPs (interface ir.a 

2, data-set multiplex 
ondlir-g six to; i-.ii-.;upiex 50 kbps Unas £ 
-ie I/O piccf.ssirig xeqflrad for full occupan 
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C. Cor-struct and install imps »nd associated interfaces 

and demonstrate the total network design a: proposed 
by the Contractor and accepted by ARPA. 

D. At the tins of completion of prototype checkout, the Contractor she 
provide system documentation in regard to the ly-.l- hardware, the consiunicatio 
software, the IMP programming language and the appropriate MOST-IMF interfac 



Message decomposition and assembly in terms of efficic 

Acknowledgement procedures. 
Routing algorithms. 
Traffic control. 



Error 



t and r 



IMP- HOST interface. 
IMP-CARRIES interface- . 
Fault recovery. 

IMP-IMP contro?. messages ar.d interrupt facility. 
Buffer sizes, erne 



Network perform 



2 estimates of the totally implemented network. 
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N. Complete inscription of the processor and paripheral equipment* 
required 

0. Description of all special purpose hardware required. 

The network contractor should include his considerations concerning the 
following optional items: 

A. Modifications for multiple HOSTS connected to one IHP 

B. Memory protection to maintain stora-and-forward operation 
during checkout of new IK progi;;-.-j 

C. Additional hardware and software necessary for tha IMP to 
be a tern-.ir.3l controller and/or ,ht 5 concentrator for its 
HOST or for the network (i.e., no HOST, just terminals). 



"It is anticipated that mass storage devices cuch as tapes, di:.ks or 
druns will not be required for the nomal operation of the 111?. 
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Abbrev. 



ransk & Newaan BBN Vo.-. i'uyo, Calif 

University HARV Cnr!>ridp,e, toss. 



Lincoln Lab LL Car.kcld^, Kiss. 

E-ll Telephone Lab. BTL Murray Hill, N. J. 



. F ro j . Agency 



Washington University WU St. Louis, Mo. 

University of Utal UTAH Salt L-J-.o City, Uteh 

Univ. of Cal. Berkeley UCB Eev.:.l:.y, Calif. 

Stanford Res. Inst. SRI Talr.- Alto, Calif. 

Stanford University SU St.-vford, Calif. 

U of C, Santa Barbara ' CC3B Sr.nt.i B.-.vb.-ira, Calif. 

U of C, Los f^ir,ele.B UCI 

HAND Corporation RAI 



CE 635 
IBM 7034 
PDP-6/10, 

CE 645 
SES <J40 

SUS 940, 



G-21 
3C0/57 
B-C500/ 

ILLIAC IV 
Spl Eqpt 
110-3 

SIo SAO, 
SCC 6700 



PU'-S, 
IBM 1S00 

3C0/50-65 



ARPA NETWOF.X TOPOLOGY 
(Example) 




All Unks arc 50 kil 



APPENDIX C 
IMP DELIVERY SCHEDULE 



University of California-Los Angeles 8-1/2 

Stanford Research Institute 9-1/2 

University of California-Santa Barbara 10-1/2 

University of Utah 11-1/2 



APPENDIX D 

>ut and Output Facilities for the IK? Operator 



Contents of the program counter 
Contents of the instruction register 
Contents of the accumulator register 
On-off state of electrical pouer to computer 
Run-halt state of computer 

Busy-idle state of each direction of each DT-HOST channel 
Transmit-no transmit state of each communication terminal 
Keceive-no receive state of each communication terminal 
Connected-not connected state of each snitched communication terminal 
In service out of service, state of eacli communication terminal 

1. Change contents of the program counter 

2. Change contents of the accumulator 

3. Turn electrical on-off to computer 

4. Cause computer ru-.i. single step, halt 

5. Cause computer to load from HOST oi communication terminal 

6. Cause computer to dump to HOST or communication terminal 

7. Cause master clear in computer 

8. Make-busy specified data tenniials 

9. Force disconnect of specified lata terminal 

10. Limit-no limit ac.ess to all o;her operator inputs 
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information is that the character text will be transf onr.ed from sending host': 
format to network standard fonr.at and then, after transmission is completed, 
to the receiving host's foritat; whereas binary text will be received bit for 
bit identical to what was sent (though sore '.v.inor modifications may be made 
during transmission, as described later) . 

ABNORMAL KS SAGES 



The forirs and types of abnormal messages have not been worked out in 
detail. It will be the Contractor's responsibility to decide what is required 
to maintain effective cormunl cations bctveen the Host and itr. UW . The cost 
important constraint is that the number and variety of these r.assages be min- 
imized so as to minimize the burden the IMP places on the Ho.it (this is a basic 
network tenet). 

Your quotation should contain suggestions of the typss of abnormal 
messages that mr.y be required. Tliis will by no r.eans be biriiinp; it is ex- 
pected that the final form of abnormal rassa;.JS will not be decided until after 
the testing of the initial (four node) network. 

I>P to IKP 




ral packets according to 
r until they reach the 



They tray even flow through different paths of network and reach the 
destination IJI out of sequential order. A r.^ssage nay also be srrall 
enough to fit into a single packet (Sir.fle Pi.cket Message, SPri) , or very 
small, e.g. single character (Very Small Mesf«&a, VSI') , All normal 
messages generate norr.il packets at sending, end visa versa at receiving. 

ABNORMAL PACK ETS 

Abnormal packets are used for error control, acknowledgements, 
and the transmission of network status, e.p. :;ew routing tables, communi- 
cation line down, Hi? down, Host d'j.vn, treasu: ;-rnt infornatic;n, etc. 
An abnormal packet may be generated by an 6br.orir.al r.-issaje or because 
of 60ts! special internal state of the IKP, e.;, buffers full. All abnormal 
packets must be acknowledged with the exception of acknowledgement and 
negative acknowledgement packets. 

packet ro?:: i\T 

The Packet Format is based on an eight bii: coda (character) format. 
The packet is sent in 3 bi t tr.-.nr.par<inc binary forn, ir.d&pesidjnt of whether 
the text is binary or character. Four speci.-.i control characters are 
required to delimit the st.-.rt and end of a p.-.c.kct and to mainioin the con- 
municaticas lino. The control characters arc-.: 



SYK(Syr.ihronizatioa character). This character is used to 




S7£(Sr-.rt of ItTtt) . Pii.-i character in die .-.res r'r.c start of a 

ETX(En<: of Text). This character indicates the end of a 
packet and must bo preceded by a DIE . Tr.a th reo character 
cyclic checksum must follow the ETX characttr. 

DLE(Pata Link Escape). Tnls character is used to indicate 
the packet is transmitted in binary for is . 0^2 is the only 

packet. If a DI.E occurs within a packet, it jnould be preceded 
by an additional HIZ on transmission, which should be deleted 
upon reception of the packet. 
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The packet should look as follows: 



S S D S Fixed DECCCS S 

Y . . . . Y 1. T Lencth IT XT L T S S S Y . . . . S 

K N E X Head?.'.- E X 1 2 3 K K 



The header is fixed length and contains all the inforrraticn required 
hy the IMF's to transir.lt the packet to its final destination. The packet 
hesader ss envisioned to dare is to contain si:; characters with the follow- 
in?, information: 

1. Destination Code (S bits) 

2. Origin Code (8 bits) 

3. Messa S a I. D. (16 bits) 

4. Packet Nutber (5 bits) 

5. Hand Over Nur'jar (6 bits) 

6. Packet rriorily (1 bit) 

7. End to End Nessaje Acknowledgement R'.-quired (1 bit) 

8. Last Packet in Kassaga (1 bit) 

9. Text is for rather then Hoot (1 bit) 
10. Test in racket is in binary (1 bit) 

ERROR COKT UPL 

detection scher.c-. Thr cycli/pariiy check corresponds to pcJ> aomial 
multiplication. ;. :,T>0 bit block of binary data ray into .tctcd as a 
polynomial a (..-.) »i dcr.rcc 959 whose coeftcients ate i an i ones. 

uct a(x)g(x> o: the f.;o polynomial:! with all cceificlorits rec.ced modulo 

two correspond:; to a i.'lcik o; 1000 + p hits ;:hich ray !>* error checked 

by polynomial divisi.r.: by -(:;). I: is possible to arrenpe natters so that 
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llic first. 1000 bits arc exactly equal to the information bits and tho la K I 
p bits arc parity chuck dibits'. This is possible from the Euclidean divi-' 
sion algorithm by selecting the ln.nl p bits la correspond to Ihc remainder 
polynomial when >il*a{x) Is reduced modulo f;(x). A p litago linear uhlft 
vcgiulor can bo coiiBtructed to perform division by ami this same, 

device can also be vised lo detect the prose;. cc of errors since that 
operation requires division .by C (x) too. The g(x) recommended is 

-x'lx -lx-i-1). The shift register which implo- 



. INPUT 

This device is used for both the generation of the checksum and error- 
detection. The device must bo cleared upon receipt of the D S sequence 

JLT 

S EX 

and started on Ihc fii-iii character following <:ho T character. 

X 

The generation of the oarity code is done by -past in" tho pa-Ket bits stream 
DE 

through the device (including the final LT)., T!io parity code is then the 
EX 

24 bits left in the device and is obtained by shifting the bits out, packing 
them into characters ,\nd transmitting them (high or do.- bit is the first ona 
of tho shift register). 

Tho detection of errors requires the passing of the packet through the 
DE 

device until LT is sensed. The in tt three characters (the parity code) 
EX 

arc input, then the 24 bits in the device are sensed for all zeros which 
indicates that no error has occurred. 

Using this parity chock scheme th ■: mean time between undetected errors 
vill bo approximately 1/2 to five > ;ars throughout the entire net.. 



NETWOrjC PACKET FORXAT 
(Exanplc) 



PRIORITY (1), FOR IMP (1), 



PACKET li(i), LAST (]), BINARY (1), EKDACK. (1) 



CONTEXT TEXT OR BINARY 0-117 CHARACTERS 



CYCLIC PARITY CHECK 



Total Length 104-1040 
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Interconnection 
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10 12 

11 9 
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a raot No. DAKC15 6 9 C 0179 

ANNEX "B" 

REQUIREMENTS FOR AR?A SPONSORED COMPACTS 



I. GENERAL INFORMATION 

a. This is an Advanced Research Projects Agency (ARPA) sponsored contract ar.d, 
as such, contains certain requirements not necessarily contained in other Covcmr.ar.-s 



b. The Contractor shall make maximum use of DoD sponsored Information Analyse: 
Centers (IAC) in the early stages of work under the contract. A list of these centers 
vill be Bade available upon request to the Director, ARPA, Attention: ARPA Technical 
Information Office, ikOO Wilson Boulevard, Arlington, Virginia 22209. 

II. DISSEMINATION 0? INFORMATION _ 

a. Classified information and ell information produced under classified 
contracts, which the Contractor proposes to release to the public, must be reviewed 
prior to such release. This applies to all types of discicsursi , e.g., cral/visual 
disclosures by presentations at unclassified meetings or documentary disclosures by 

. publication of papers in technical Journals. It includes publicity releases, sales 
brochures, advertisements, etc. Requests for permission to release such informatics 
shall be submitted; in five (5) copies, by the Contractor oirectly to the Director, 
ARPA, Attention: Security Review Officer. 

b. Unclassified in'irmation not generated under classified contracts, such- as 
■basic research performed by Universities under fundamental research contracts, does 
cot require review and approval in accordance with a. above. 

c. Unclassified information developed under unclassified contracts awarded to 
colleges and universities may be released to the public without review and approval 

required by the researchers either during the development of the program or durir.,; the 
performance of the contract and provided further that release of the information is 
not otherwise limited by the terns of the contract. . 

III. CONTRACTOR REPORTS 

• The contract will specify the reports, chosen from those listed below, that ere 
required under the contract. Reports shall be prepared in accordance with the 
guidelines contained herein. Deviations in content, format or frequency must be 
approved in writing by the Contracting Officer. 



DSS-M 

Rev. 7/1/72 



a monthly or quarterly frequency. Two (2) copies of Management Reports should b 
submitted to A3PA, Attention: Progras Kanase.--.ent, by the Contractor within 15 d 
after the close of the reporting period. The following symbol shall be' procir.cn 
displayed on the cover of each Management Report: Forr. Approved, Budget Bureau '. 
22 - E0293. The initial reportins period will begin on the first day of the r.on 

cover three^f^onths of"eff ort V^vill^ot necessarily fall Vu^on' cLler.dar'q 
The Contractor shall notify AKPA procptly^ of any r.ajor occurrence of a^ technical 

b. The Management Report should be in letter form and, .generally, should r 
exceed three (3) pages in length. Its priaary purpose is to infom A?PA aanage-e 
of significant events, accorplishcents, end problem associated vith the progress 
vork. The report should represent a narrative sumary'of the work underway and s 
be prepared to reflect the topics outlined below. Any of the topics below s-.ay be 
covered by noting such coirr.-2r.ts as "none," "not explicable," or "no significant c 
vhen appropriate. (The Managecent Report should .-.ot be used to d^curient technic 

technical reports.) ■ > e. °P 

1. Research Pro.cr—i Plan . A brief statecer.t of the program's objectiv- 
and the plan for research should be shown in this itesi. 

2. Ka.lor Accorolishr . ar.ts ■ A brief description, written in r.or. -technic 
teres, of any findings or a ccorroli shunts that should be arcurht -.0 the attention 
ARPA saaasataat. The accooplishsant of cajcr nilcstases (where the regular tiler 
report described below is not required) or the occurrence cf technological 
breakthroughs should be reported. 

affected, or could affect the progress of the vor'.:. These would include probier. 
of ca.-iager.ent significance such as: Personnel, facilities, contracts, funds, str. 
disasters, etc, Significant problens of a technical na-unj should also be inciud" 
in brief, non-technical terns. 

^ ' k. Fiscal Status . (Items 3 and C belcw required for Cost Type Contrac 

A. Acount currently ■ rovided for contract (or in-hcuse program). 
■B. Expenditures and corcitcsnts to date. 

C. Estimated funds required to corslete the work. 

D. • Estimated date of completion of work. 



5- Action RecuUed by AR?A or the Contract Arent . Generally, this iter, 
vill entail the assistance required in resolving "Problem Encountered." 

6. Future Plans . A brief statement of any significant change which is 
planned in the course of the work or any new iten considered to be of interest to 
nanagerent . 



the Report of Progress Against Selected Milestones' (SD*Fom 350) should be subritte'. 
to A EPA, Attention: Program Kanage.-rent , on a monthly basis vithin 15 days after th- 
close of the reporting period. 

a. A list of suggested milestones is to be submitted by the Contractor to A?J 
and the contracting agent vithin 1*5 days fron dat« of this ATPA Order/A-cndse.-vc . 
(Milestones are defined as points of accomplishment which represent significant 
progress when cotnpleted.) 

b. Milestones should include r.ajor phases of hardvare developr^nt and testin; 
decision dates on alternate approaches, dates by v.-dch control information on 
facilities or government equipment is required, dates by which a capability =ust be 
demonstrated, delivery dates and other significant phasing and tiair.g points. 

c. Copies of SD Form 350 (Report of Progress" Against Selected Mlestcr.es) vi] 
be furnished the Contractor if milestone reporting is required. This fora will 
provide further guidance for the selection of rilestcr.es and for the preparation of. 



technical EPGRTS 

a. The report will present a concise and fact 
findings and accorplishiients during the period. Che 
publication quality, including appropriate subject = 
of each report will be submitted directly to the Eir< 
JUmagensnt. The reports are due vithin 30 days fell! 
period. The initial reporting period will begin or. ■ 
following the date perforaar.ee under the contract be; 
-technical reports vill thus cover three (3) or six (< 
necessarily fall due on calendar quarters of half ye: 

b. A final technical report is to be prepared 
effort. Two (2) copies of this report should be sub; 
Attention: Program Managerant vithin 60 days after i 
report shall erjhasize the acco=?lishr.ents during thi 



upon cocpletioa of this^rei 
oaletion of the research, 
esults over the entire peri 



c. Each Technical Report, v ill include a report s unwary. This ! 
prominently identified, should normally not exceed a few pa.^s. The 3 
project r.ust be specified, together with a description of isportent e( 
or developed, if any, and the conclusions reached by the Contractor, 
iinnortent single feature of this sur.-a.ry is that it must be aaaningfuJ 
are not specialists in the subject natter of the contract. 

d. The rcqui.reir.ent for careful preparation cannot be over-eirphs 
sua:nary will often provide the basis for decisions on 
Contractor Kust recognize that his achieversnts are quit 
of Defense staff vho function at a level that precludes 
reports . 

e. Where appropriate, references should be =ace to z-.ore del 
report in order to guide those who nay be prepared to spend the at 
required to develop a core cocylete and professional understanding 



continuity of a projec 
often surveyed by Dana- 
. thorough reviev of det 



1. Technical problea 

2. General cethodolosy (e.g., liti 
survey, field study, etc.) 

3. Technical results 

ft. Indications for further resesj 
5. Special concents (if any) 
KEPOBTS F03MAT AKD DISTRIBUTION 

r page of each : 



1 the following 



AHPA Order Nuaber 
Prograa .Code Number 



Contract ITuaber 



i of Contractor 



• Effective Date of Contract 
Contract Expiration Date 
Amount of Contract $ 



* l"he contract vill specify the ARPA Order Kuibcr and Progran Cods 



b. Each report prepared will include the following citation on the cove: 

Sponsored by 
Advanced Research Projects Agency 
ARPA Order Mo. ■__ 



c. Each publication resulting froa ARPA work vill contain the following; 
acknowledge cent : 

{This research was supported by the 
Advanced Research Projects Agency 
of the Eepart.-r.ent of Defense under 
Oontract No . . 



d. Disclaimer . Each Technical Report produced under ARPA Orders will ha 
prominently displayed on front of the document, a notice of disclaimsr worded 
substantially as follows: ' . 

She views and conclusions contained in this document are those 
of the authors and should not be interpreted as necessarily 
representing the official policies, either e:c?ressed or implied, 
of the Advanced Research Projects Agency or the U.S. Government. 

e. 1. Two (2) copies of each Contractor report (Management or Technical 
generated on ARPA Programs shall be submitted to: 

Director 

Advanced Research Projects Agency 
ATTN: Program J^nager.ent 
lUOO Wilson Boulevard 
Arlington, Virginia 222 09 

2. Two (2) copies* of each technical report only , generated on ARPA 
shall be subnitted to: 

Defense Docuoentation Center 
Cameron Station 
Alexandria, Virginia 

• Twelve (12) copies if report is unclassified and unlimited; 

Two (2) copies if report is classified or licited. 

3. One (1) copy of each technical report resulting froa work perforz 
area of tactical technolosy shall be sent to; 



TACTEC 

Battelle 2{eaorial Institute 
505 King Avenue 



It. One (l) copy of each technical report resulting from wor>: performed i 
area of the strategic technology shall be sent to: 

STOIAC 

Battelle Kerorial Institute t 
505 King Avenue 
Columbus, Ohio 1»3201 

5. Each copy of any Technica l Report required under this contract shall 1 
accompanied by a cocpleted Document Contral Data - ?,£D (DD ?ora 1^73) as set forth : 
ASPS [ -i-U2. 



7. Additional distribution of technical reports as specified in t 
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ANNEX "C" 
ACCOUNTING AND APPROPRIATIONS 



97X0400. 1311 3 1260 F8D30 1220 ( 51 5 ) -S 49 1 5 6 DDP19 2 - $5 6 3 , 000 . 00 
97X0400.1311 1260 P9D30 1220 S49156 DDP253 - $514,727.00 
97X0400.1311 1260 P0D30 1229 S49156 DDP372(M) - $878,461.00 
97X0400.1311 1260 P9D30 1229 S49156 DDP3 76 (M)-$34, 273.00 



97X0400.1311 1260 POD: 

97X0400.1311 1260 PIP: 
971/20400. 1311 1260 P: 

97X0400.1311 1260 PIP: 

9720400.1311 1260 P2P: 
9720400.1311 1260 

9720400.1311 1260 P2D. 

9720400.1311 1260 P2P 

9720400.1311 1260 P2F: 

9720400.1311 1260 P2K: 

9720400.1311 1260 P2F 

9730400.1311 1260 P3P 



0 1229 S49156 DDP4 74 CM) - $39 3 , 25 2 . 00 

0 1229 S49156 DDP566 (M) - $1 , 2 5 8 , 075 . 00 
P10 1229 S49156 DDP648 (M)-$ 226,075. 00 

0 1229 S49156 DDP6 5 6 (M) - $ 1 9 , 9 22 . 0 0 

0 1229 S49156 DDP 72 6 (M) - $1 , 5 2 7 , 00 D . 00 

0 1229 S49156 DDP 7 84 (M) - $89 , 706 . 00 

0 1229 S49156 DDP7 84 (M) - $ 110 , 000 . 00 

0 1229 S49156 DDP789 (M) -$321 ,000 . 00 

.0 1229 S49156 DDP820 (M) - $1 35 , 767 . 00 

1229 S49156 DDP 82 1 (M) -$14 7 , 79 3 . 00 

.0 1229 S49156 DDP822 (M) - $54 7 , 5 20 . 0 0 

0 1229 S49156 DDP9 05 (M) - $ 7 32 , 741 . 00 



9730400.1311 1260 P3E30 1229 S49156 DDP9 60 (M) -$9 7 , 626 . ! 



2A 9720400.4300 2479 22JT 1220 S49204 DC4604-$ 335 , 500 . 00 
2B 9730400.4300 2479 33JT 1220 S49204 DC 4602-$ 31 , 254 . 00 
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ANNEX "D" 
LIST OF CONTRACTOR'S PROPOSALS 



within 



al No 
ugh 9 

i Proposal No 

Proposal No 



and amending Letter 
P71-CSY-1D (Option 
excluding installat 
England. 

Contractor ' s 

Contractor ' s 



isal No 
isal No 



Contractor' 



Proposal No 
Proposal No 
Proposal No 
Proposal No 



31 March 1972. 



Contractor's Proposal No 
9 June 1972, as amended ; 
November 1972, and 19 Janua: 



1-CSY- 
1-CSY- 



2-CSY-: 
2-CSY- 
2-CSY- 

2-CSY-: 
2-CSY- 



'2-CSY-: 



BBN 



-CSY-: 

N let 
y 1973 

2-CSY-. 
2-CSY-: 



, dated 7 August 1970. 

B, dated 1 February 1971. 

C (Option 2), dated 14 June 1971, 
12 July 1971, and Proposal No. 
■ 1971, as amended 9 July 1971, but 
exandria, Virginia) and London, 

, dated 9 August 1971. 

-A, dated 3 December 1971 

B (Options A, C. D. E, F, and G) , • 

-H, dated 28 February 1972. 

B (Option I), dated 25 April 1972. 

B (Option J), dated 25 April 1972. 

B (Option B, Revision 1), dated 



B (Option K, Re\ 



sion 1), dated 



Revis 



. 1A) , dated 



1972, 21 
B (Option M, Revision 1) dated 
B (Option N, Revision 2), dated 
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DELIVERY SCHEDULE FOR ITEM 0001 



SITE NAME 



California 



Santa Barbara, California 
Salt Lake City. Utah (516) 



, Massachusetts 



, California 



, California 



NASA/A*ES (516) 



California 



: 1 - Continue 



SITE NAM E 

MITRE (TIP) 
McLean, Virginia 



TINKER (316) 



California 



: AFB, Nebraska 
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a. The Coi 
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■ promptly of ai 



primary purpose is to inform DCA of s: 
roblems associated with the progress i 

the following topics. 



he Managene 
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ired by DCA 



manageroei 



DEFENSE ADVANCED RESEARCH PROJECTS AGENCY 



MEMORANDUM FOR THE OIRECTOR, PROGRAM MANAGEMENT 
SUBJECT; Amendment to ARPA Order 3214 - Bolt Beranek and Newman 
References: a. BBN Proposal P77-CS4-11 



k Statett 



tif icatio 



It is requested t 
to Defense Supply Serv 
Bolt Beranek and Newma 



□ SIMPs and gateways f 



rder 3214 be issued for 8336,794 
contract MDA SB3-7S-C-B252 with 
r proposal P77-CSY-11. The 



OBJECTIVE: 

The objecti 
SIMP/Gateuay eqi 
COMSAT Laborator 
Atlantic Satell i 
SIMP/Gateuay eqt 



t Earth Station a 
d UK portions of 



BACKGROUND AND TECHNICAL NEED: 

The Atlantic Packet Sate 1 1 i 
Goonhilly Doun9, UK. Uith this 



3 Interf 



termine 9 the effee 



otted ALOHA and 

in the SIMPS to 
n and analysis. 



I aspects requir 
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RELEVANCE TO THE ODD/ARPA MISSION AND FUNCTIONS: 

Broadcast Packet Satellite Communications can make available, dynamically, 

the earth and in that region uhere it is most needed. Far more effective use of 

with fixed allocation techniques. This technique provides a more cost-effective 
system, better utilization of DoD resources and most importantly, it provides 
the ability to dynamically apportion the satellite capacity during crisis 



TRANSFER PLAN TO THE SERVICES: 



WORK : 



contkacto 

FUNDING : 



P. MANAGER: Various 



PE CODE 
62708E 



TERM (M O) FUND TO : 
3 9-30-76 



1956-07 
2496-05 
3214-01 



:rypticr. Device Dev Walker 
Interface 



T12001I 
T120041I 
T12006I 
T12007I 
T1200SI 
T12010I 
T120091I 



3092-03 
3173-01 
2223-14 
2641-02 
2496-05 
3186-01 
3225-01 



bss-i; 

idio D5S-V 
DSS-W 

hss-v 

nstru ECOM 

DSS-'. 
DSS-V. 
ES.O 
DSS-' 
DSS-i. 
DSS-i 



DSS- 



1 6 SEP 1972 

MEMORANDUM FOR THE DIRECTOR,. PROGRAM MANAGEMENT 

SUBJECT: System* Design of a World-wide Seismological 
Communications Network 

References: ; 

1. COMSAT letter to AFOSR dated 29 August 1972, Subject: 
Proposal for Systems Design of the World-wide Seismological 
Communications Network. 

2. Letter OSR to ARPA dated 5 September 1972. 

3. CCD Working Paper 388, 1972, Subject: A Review of Current 
Progress and Problems in Seismic Verification. 

It Is requested that $66,443 of FY73 Seismic Verification funds be 
transferred to the Air Force Office of Scientific Research to support 
a systems design study by COMSAT of a world-wide seismological 
co mm u n ications network. 

Objective 

To design an economically and technically feasible satellite communi- 
cation network for the purpose of providing the satellite portion of 
direct digital data links between selected seismic arrays and long- 
period seismic stations to the Seismic Array Analysis Center In 
Alexandria, Virginia. 

Background and Technical Need 

A recent working paper prepared for the CCD, Reference 3, reviews 
the current status of U. S. research into seismic verification of an 
underground nuclear test ban, Identifies problem areas in that research, 
and describes future research approaches designed to assist in solving 
the identified problems. One of the research areas discussed in the 
paper was concerned with future seismic data communications systems 
and data analysis procedures. 



• The proposed communications system described In the TCD working 
paper would provide regular, but not necessary real time, trans- 
mission of processed data from, individual seismic arrays or stations 
to an analysis center using satellite communication facilities. The 
current INTELSAT satellite communications network is an in-being 
system with world-wide coverage and ground terminals in many countries 
of the world. Data collected at seismic stations throughout the world 
would be available to all who wish to use it by intercepting the data 
enroute to the analysis center or extracting the raw or processed data 
from the analysis center data bank on demand. 

Solving the problem of designing an optimum verification system which 
seeks to detect all events, on a world-wide basis, above a body wave 
magnitude of approximately 4. 0 requires a good deal of operating ex- 
perience. Such a system is crucially dependent on the quality of system 
management and communication when experience indicates there are in 
excess of 20. 000 events in this category per year. 

The work proposed by COMSAT seeks to explore the feasibility and 
design of communication satellite links to bring back seismic data from 
a world-wide seismic network to a central analysis center. 

This work is an integral part of the ABFA seismic verification program. 

Proposed Effort 

The proposed work is a six-month effort to evaluate the communications 
requirements of a world-wide seismic network and to define the pre- 
ferred configurations for all satellite communications links involved. 
Both technical and economic factors will be considered. 

Sites to be connected initially would be the NOR SAB array located at 
KJeller, Norway and the eight very long period (VLP) seismic stations 
located outside the continental U.S. These sites are: 

Charters Tower, Australia 
Eliot. Israel 
Chen Mai, Thailand 
Kongsberg, Norway 
Matsushiro, Japan . 
La Fa*. Bolivia 
Kipapa, Hawaii 
Toledo, Spain 

Other long-period stations and arrays under consideration will be added . 
to the study aa each location is approved. 
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Except for the NORSAR Array, all work In this study will be conducted 
through the NQAA, Albaquerque Self Biological Center which is the ARPA 
coordinator for the world-wide VLP station experiment and U expected 
to be the ARPA prime agent /or future arrays. Coordination with 
NORSAR will be handled by OSR through the Air Force Systems Command, 
Electronic Systems Division (ESC), the current NORSAR agent. 

Based on favorable results from this study, implementation of selected 
communication satellite links will be proposed beginning in late FY73 or 
early FY74. 

A parallel effort is proceeding to design and develop the data links within 
the U.S. and the S-Umic Analysis Center data storage and analysis plans 
required to complete a prototype world-wide seismic data processing and 
analysis system. 

Relevance to DoD/ARPA Function and Mission 

This work is designed to develop the design of a satellite communication 
system which would transmit data from selected seismic stations through- 
out the world to-a central seismic data analysis center in the United 
States. The U. S. technical objective for research in support of seismic 
verification of an underground test ban treaty is to investigate the appli- 
cations of modern technology to the task of implementing a future world- 
wide seismic network, t. -As- one aspect of that objective., this work will 
st udy the use of world-wide satellite communications to provide the near- 
real time data communications proposed for the future seismic network. 
This work supports the technical discussions of a Comprehensive Test 
Ban Treaty. 

Assessment of Environmental Consequences 

This work Involves the design of a communications system utilizing the 
INTELSAT communications satellite system to support data collection 
from a world-wide seismic network. It Is expected to have a neutral 
effect on the environment. No Environmental Impact Statement is con- 
sidered necessary for this work. 

Administrative Considerations 

1. Cost: $66,443. 

2. Funds are available on line Fl 4501. 
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3. The four tasks described In the COMSAT propoaal, Reference 1, 
are Acceptable with tbe following exceptions: 

Design studies involving arrays other than NOR SAB. will be 
performed only with the specific prior authorization of the 
aVRPA program manager. 

Design studies involving VIP stations will be restricted to 
the following sties initially: 

Charters Tower, Australia. 
Eliot, larael 
Chen Mai, Thailand 
Kongebcrg, Norway 
Mataushiro, Japan 
La Pas, Bolivia 
Kipapa, Hawaii 
Toledo, Spain 

Design studies of other VIP sites will be initiated only with 
the prior authorization of the ASP A Program Manager, 

4. Monthly progress reports and a final technical report are 
requested. 

5. In Reference 2, AFOSR has agreed to serve as agent and should 
be so designated. NOAA will be co-monitor of the COMSAT contract. 
NOAA will coordinate all contacts of COMSAT personnel with Directors 
of VIP stations. 

6. Sole Source Selection Justification is attached. 

7. The proposed work has been discussed with ISA, Foreign 
Military Rights Office. ISA recommended that the COMSAT study be 
conducted through the existing NOAA agreements with the VIP station 
directors in each country. The COMSAT work is effectively an ex- 
ploration of improved techniques to obtain data from each VIP station 
and does not require a new agreement. 

Contacts with NORSAR on this work will be conducted through ESD 
at part of the current NORSAR program as an exploration of improved 
techniques to obtain data. 



8. NSF Code»: ^pa of "Work, B; Field of Sclent, 49! Per- 
forming Organization, 5. 

9. Program manager will be Colonel D. C. Raesell. 



S Encle 

1. Kef. 1 

2. Ref. 2 

3. Sole Source Relevance 

Statement 



Eric H. Willie 
Director for 

Nuclear Monitoring Reeearcb 



COORD: Dr. Fryklund 

Col Pearce 

ColDolan. IPT 
Dr. Roberts 



Prepd: Col Russell/5Sep72 
NMRO/43147/hcb 
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PARI II - THE SCHEDULE 



SECIIOH E - SERVICES AND PRICES 



0001 



1. STATEMENT OF WORK : 



$27,585 



The contractor shall furnish scientific effort during the period 
and at the level Indicated below, together with all related services, 
facilities, supplies and materials, toward the design of a world-wide 
seismo graphic communication system for the purpose of bringing seismic 
data via satellite communication from a number of seismic arrays and/or 
stations distributed around the world to the Seismic Array Analysis 
Center in Alexandria, Virginia. 

The work to be included is as follows: 

a. Participate in the packet-switching experiment to be 
performed between the U.S. Earth Station at Etam, West Virginia, and 
the U.K. Earth Station at Goonhilly. 

b. Coordinate the testing of SIMP and SPADE systems. SIMP 
refers to Satellite Information Message Processor. SPADE refers to 
Single channel per-carrier, Pulse code modulation multiple Access 

e. Coordinate the planned experiment for the packet- switching 
experiment to be conducted via satellite between the U.K. and U.S. Earth 
Stations. 

d. Build and test two experimental interface units for the 
ARPA net. These units will be delivered to ARPA and ARPA will provide 
the units for use in the program. 

e. Build and test an experimental data test set. The test set 
will be delivered to ARPA and ARPA will provide it for use in the pro- 
gram. 

2. LEVEL OF EFFORT : 

During the period of performance set forth in Section B, the 
Contractor will expend research effort as follows: 



Level-of-Ef fort 



Category 



Man-Hours 



Systems Studies (Scientific) 



470 
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3. PAYMENT ! 

a. The total fixed price of this contract is $27,585. Progress 
payments are authorized under conditions set forth in the clause 
"Progress Payment for Other than Small Business Concerns (1974 APR)". 

b. The total fixed price shall be subject to downward only 
adjustment. Said adjustment will be based upon the Contractor's 
records of actual laboratory man-hours of effort expended in the 
contract period and during the precontract period. For each hour less 
than the prescribed level-of-ef fort, the contract price may be reduced 
$49.26. Final payment is further subject to acceptance of the final 
technical report. Adjustments based upon the Contractor's records of 
hours of effort shall be made by the Contracting Officer in consultation 
with the Contractor. 
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0002AA a. MANAGEMENT REPORTS 

(1) Type and Frequency of Report : At the end of each complete nnt» 

month period after the work begins, a monthly Management Report 

will be prepared for that period. The initial reporting period will begin 
on the first day of the month following the effective date of the contract. 
Thus, Quarterly Management Reports will not necessarily fall due at the end 
of a calendar quarter. Reports are due IS days after the close of the 
reporting period. 

(2) Description of Report : The Management Report should be in letter 
form and, generally, not exceed three (3) pages in length. Its primary 
purpose Is to inform ARPA management of significant events, accomplishments, 
and problems associated with the progress of work. The report should pre- 
sent a narrative summary of the work under way and should be prepared to 
reflect the topics outlined below. Any of the topics below may be covered 
by noting such eonnents as "none", "not applicable", or "no significant 
change" when appropriate. (The Management Report should not be used to 
document technical progress or contain technical charts, graphs or formulas. 
Such data belong in the Technical Reports.) 

Research Program Plan . A brief statement of the program's 
objectives and the plan for research should be shown in this Item. 

- Krim Accomplishments , a briet description, written in non-rerh- 

nlcal terms, of any findings or accomplishments that should be 
brought to the attention of ARPA management. The accomplishment 
of major milestones or the occurrence of technological break- 
throughs should be reported. 

Problems Encountered . This Item should Include difficulties 
which have affected, or could affect, the progresa of the work. 
These would include problem areas of management significance 
such as: personnel, facilities, contracts, funds, strikes, 
disasters etc. Significant problems of a technical nature should 
be included In brief non-technical terms. 

Fiscal Status. 

(a) Amount currently provided for contract. 

(b) Estimated expenditures and commitments to date. 

(c) Estimated funds required to complete the work. 

(d) Estimated date of completion of the work (when different from 
that specified in the contract). 



Note: When required by the ARPA Order, Insert "one" or "three", "Monthly" 
or "Quarterly" In the spaces provided in para a (IX If no Management Report 
Is required by the ARPA Order, insert "Not Required" after "MANAGEMENT 
REPORTS" . 
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Action Required by ARPA or AFOSR . Generally, this item will entail 
the assistance required in resolving "Problems Encountered". 

Future Plana . A brief statement of any significant change which is 
planned in the course of the work or any new item considered to be 
of Interest to management. 



0002AB b. TECHNICAL REPORTS 

, (1) Type and Frequency of Report : The type of report (s) Indicated below 

[ ) A Technical Report will be prepared at the end 

of each complete month period. The initial reporting 

period vill begin on the first day of the month following the 
effective date of the contract. Reports are due 30 days after 
the close of the reporting period. 

[ ] At the end of each year of work, except for the final year, 
an Annual Technical Report will be prepared for that period. 
Reports are due 30 days after the close of the reporting period. 

(X] 60 days after the end of the research period, a comprehensive 
Final Technical Report is due. Should the research effort be 
. . rscevsd bsyond the initial year.. sr. Annual .Tecanieel-Rsyort 

will automatically be required for each additional year of 
work, except the final year, and the Final Technical Report 
postponed until the end of the renewal period. 

(2) Description of Report : The reports required will present a concise 
and factual discussion of technical findings and accomplishments during the 
reporting period. The report should be of technical publication quality, 
including appropriate subject matter references. 

(3) Technical Report Summary . Each Technical Report will include a 
report summary. This summary, prominently identified, should normally not 
exceed a few pages. The purpose of the project must be specified, together 
with a description of important equipment purchased or developed, if any, 
and the conclusions reached by the contractor. The most Important single 
feature of this summary is that it must be meaningful to readers who are not 
specialists in the subject matter of the contract. 

The requirement for careful preparation cannot be overemphasized 
. as this summary will often provide the basis for decisions on the continuity 
of a project. The contractor must recognize that his achievements are quite 
often surveyed by Department of Defense staff who function at • level that 
precludes a thorough review of detailed reports. 



Note: Enter "x" in the appropriate block as required by the ARPA Order. 
Insert "Quarterly" or "Semi-Annual", "three" or "six" if required by 
the ARPA Order. 
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Where appropriate, references should be made to more detailed 
sections of the Technical Report in order to guide those who may be 
prepared to spend the additional time required to develop a more 
complete and professional understanding of the accomplishments. 

This report summary should include the following information 
for each experiment or program: 

(a) . Technical problem 

(b) General methodology (e.g., literature review, laboratory 
experiment, survey, field study etc.) 

(c) Technical results 

-(d) Implications for further research (if any) 
(e) Special comments (if any) 



COVER PAGE INFORMATION 

d each Technical Report 

(a) ARPA Order 2298 (g) Contract Number 

(b) Program Code 5T10 0>) Principal Investigator 

(c) Name of Contractor and Phone Number 

(d) Effective Date of Contract (i) Program Manager and Phone 

(e) Contract Expiration Date Number 

(£> Asount cf Contract Cellars (J) Shirt Title of Work 



Sponsored by 
Advanced Research Projects Agency 
ARPA Order No. 2298 



PUBLICATIONS 



(1) Publication of the results of unclassified research projects in 
appropriate professional journals is encouraged as an important method 
for recording and reporting scientific information. 

(2) Each publication will contain the following acknowledgement: 

"This research was supported by the Advanced Research 
Projects Agency of the Department of Dafensu and was 
monitored by the Air Force Office of Scientific Resairih 
under Contract No. F44fi?0~7 l-fT-OQq? •" 




• e. DISTRIBUTION OF REPORTS , 
(1) MANAGEMENT REPORTS , 

(a) Three copies of each report will be submitted under a cover 
letter addressed to: 

Air Force Office of Scientific Research 

ATTN: NP 

1400 Wilson Boulevard 

Arlington, Virginia 22209 

(b) Two copies of each report to: 

Director, Advanced Research Projects Agency 
ATTN: Program Management 
1400 Wilson Boulevard 
Arlington, Virginia 22209 

(c) Two copies of each report to the AFOSR Contracting Officer. 

(2) TECHNICAL REPORTS 

(a) 16 copies of each report will be submitted for inspection 
and acceptance under a cover letter addressed to: 

Air Force Office of Scientific Research 
ATTN: 

1400 Wilson Boulevard 
Arlington, Virginia 22209 

(b) Two copies of each report to: 

Director, Advanced Research Projects Agency 
ATTN: Program Management 
1400 Wilson Boulevard 
Arlington, Virginia 22209 

(c) One copy of each report to the AFOSR Contracting Officer. 

(d) Additional copies of Technical Reports (normally not to 
exceed 50) will be distributed as may be directed by the 
AFOSR program manager under separate letter. 

f. DISTRIBUTION OF PUBLICATIONS 

S copies of each paper planned for publication will be submitted 
to the AFOSR program manager simultaneously with its submission for publi- 
cation, and »; reprints of each published paper will be submitted 
immediately following publication. Up to 100 additional reprints may 
be distriouted to other addressees' furnished or approved by AFOSR. 



Rote: Insert the appropriate office symbol in para e(l)(a) and e(2)(a). 
Insert the appropriate number of copies in para f, per the instructions 
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SECTION H - PERFORMANCE 

1. PERFORMANCE ; 

a. Research shall be conducted during the period 1975 May 1 through 
1975 August 31. 

b. The contractor shall use due diligence to complete this contract 
within the period specified; provided, however, that the time for com- 
pletion of performance may be extended at the discretion of the contracting 
officer by modification to the contract. Any extension of time under this 
provision shall not, of itself, form the basis for incurring additional 

SECTION I - INSPECTION AND ACCEPTANCE 

0002 1. REPORTS DELIVERY AND ACCEPTANCE 

The reports required hereunder shall be submitted for inspection 
and acceptance to the addressee shown in Section E.4.e.(2) (a). 

SECTION J - SPECIAL PROVISIONS 

1. The principal investigator for the contract is Dr. Jorge C. Fuenzalida. 
No substitution will be made without the prior written approval of the 

. Contracting Officer. 

2. PRECONTRACT COSTS 

The price of this contract includes expenses of $6,587 incurred on 
and after 15 March 1975 by the contractor in anticipation of this contract 
and prior to the effective date thereof. The precontract period includes 
90 hours of scientific effort. 

SECTION K - CONTRACT ADMINISTRATION DATA 

1. PATENT COUNSEL 

AFOSR/JA 
Patent Counsel 
1400 Wilson Blvd. 
Arlington, Virginia 22209 
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PART III - SECTION L 



- GENERAL PROVISIONS 



The following specific clat 



1. USE OF TECHNICAL INFORMATION SERVICES 

To the extent practical, the contractor agrees to use the technical 
reference facilities of the Defense Documentation Center for Scientific 
and Technical Information, Cameron Station, Alexandria, Virginia 22314, 
and all other sources, whether Government or private, for the purpose 
of surveying existing knowledge and avoiding needless duplication of 
scientific and engineering effort. 

2. SECURITY 

If, in the conduct of the research, the contractor develops 
information which in his opinion might have an adverse effect on the 
national security if it were disclosed he should promptly notify the 
program manager and should not disclose the information without the 
prior concurrence of the contracting officer. 
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3. DOCUMENTATION OF SCIENTIFIC AND TECHNICAL REPORTS 



A DD Form 1473 (REPORT DOCUMENTATION PAGE), completed in 
accordance with the Instructions contained thereon, shall be 
Included with each copy of scientific and technical reports 
required to be submitted under this contract. 

4. RESTRICTIONS ON PRINTING (1974 JUN) 

Duplication of reports, data or other written material, if 
required, is authorized provided that the material produced does 
not exceed 5,000 production units of any page and that items 
consisting of multiple pages do not exceed 25,000 production 
units in the aggregate. The aggregate number of production 
units is to be determined by multiplying pages times copies. 
For purposes of this paragraph a production unit is one sheet, 
size 11" x 17" or less (10-3/4" x 14-1/4" maximum image), one 
side only, one color. Duplication of material in excess of the 
quantities cited above shall not be accomplished without express 
prior written authorization from the contracting nfflrpr. Th»s» 

manuscript or reproducible copy of related illustrative materials 
if required as a part of this contract. They do not apply to the 
printing or duplicating required by contractors for their own use 

5. RIGHTS IN DATA (1967 DEC) 

The rights obtained by the Government in technical data are set 
forth in the Rights in Technical Data clause incorporated in the 
contract, and nothing elsewhere in this contract or in any documents 
incorporated by reference in this contract shall be construed as in 
any way altering such rights except as restricted by the express 
terms, if any, of this contract as to data called for and furnished 
for provisioning purposes only. 
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6l ' ABSTRACT OF NEW TECHNOLOGY 

The contractor agrees to submit an Abstract of New Technology 
describing each item reportable as a subject invention under the 
Patent Rights clause. The abstract shall be considered a part of 
the technical disclosure of each reportable item and may be pre- 
pared by the originator (inventor). The abstract will be in 
reproducible condition on 8^ by 11-inch bond. A 1-inch space 
will be left blank at the top (short side) of each sheet. The 
abstract will contain: 

(i) Title. A short meaningful title specifically identifying 

(ii) Graphics. Any graphics which might aid in illustrating 
the item and how it functions (illustrated by drawings, sketches, 
photographs, numbers, and descriptive names, if possible). 

(iii) Description. Sufficient information to enable a person 
skilled in the art to determine quickly, from a cursory Inspection, 
the principal structural elements and function as well as the 
results afforded thereby. 

(iv) Source. Inventor's name, company, organization or 

(v) Publication.' Identification of the date and identity of 
any public use or publication of such item made by or known to 
the contractor, or of any contemplated publications by the 
contractor, including h"f nnr limited to published reports, 
patent applications, or journal articles. 

(vi) Notice. Add the following warning at the bottom of the 
first page of the Abstract: 

"This document was prepared under the sponsorship of the Air Force. 
Neither the US Government nor any person acting on behalf of the 
US Government assumes any liability resulting from the use of the 
information contained in this document or warrants that such use 
will be free from privately owned rights." 

7 ' DELAYED DELIVERY OF ABSTRACTS OF NEW TECHNOLOGY 

Whenever the contractor is authorized under the Patent Rights 
clause of this contract to file a United States patent application 
claiming a "Subject Invention," and elects to do so within the time 
provided in such clause, the contractor may delay delivery of the 
Abstract of New Technology until such time as the contractor delivers 
the completed disclosure or a copy of the patent application as 
required by the Patent Rights clause. 
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DELAYED DISSEMINATION OF ABSTRACTS OF NEW TECHNOLOGY 



When the contractor, if authoi 
of this contract, has elected to t 
patent application, the Government 
contractor, delay dissemination of 
for a period not to exceed one yea 
additional delay may be authorized 



rized by the Patent Rights clause 
Eile a domestic and/or foreign 
t may, upon request of the 
E any Abstract of New Technology 
ir. In exceptional circumstances, 
i upon a showing of good cause. 
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ASPR Paragraph Clause Title and Date 

7-103.1 DEFINITIONS (62 FEB) 

7-103.6 TITLE AND RISK OF LOSS (68 JOT) 

7-103.8 ASSIGNMENT OF CLAIMS (62 FEB) 

7-103.10 (b) FEDERAL, STATE AND LOCAL TAXES (71 NOV) 

7-103.12(a) DISPUTES (58 JAN) 

7-103. 13(a) RENEGOTIATION (59 OCT) 

7-103. 16(a) CONTRACT WORK HOURS AND SAFETY STANDARDS ACT -OVERTIME 

COMPENSATION (71 NOV) 

7-103. 18(a) EQUAL OPPORTUNITY (72 AUG) 

7-103.19 OFFICIALS NOT TO BENEFIT (49 JUL) 

7-103.20 COVENANT AGAINST CONTINGENT FEES (58 JAN) 

7-103. 21(b) TERMINATION FOR CONVENIENCE OF THE GOVERNMENT (73 APR) 

7-103.23 NOTICE AND ASSISTANCE REGARDING PATENT AND COPYRIGHT 

INFRINGEMENT (65 JAN) 

7-103.26 PRICING OF ADJUSTMENTS (70 JUL) 

7-103.27 LISTING OF EMPLOYMENT OPENINGS FOR VETERANS (73 SEP) 

7-104.3 BUY AMERICAN ACT (64 MAY) 

7-104. 9(a) RIGHTS IN TECHNICAL DATA AND COMPUTER SOFTWARE (74 NOV) 

7-104. 9(h) TECHNICAL DATA -WITHHOLDING OF PAYMENT (74 NOV) 

7-104.9(1) IDENTIFICATION OF TECHNICAL DATA (75 MAR) 

7-104. 9(p) RESTRICTIVE MARKINGS ON TECHNICAL DATA (75 MAR) 

7-104. 14 (a) UTILIZATION OF SMAJ..T. BUSTNESS CONCERNS (5R JAN) 

7-104.15 EXAMINATION OF RECORDS BY COMPTROLLER GENERAL (71 MAR) 

7-104.16 GRATUITIES (52 MAR) 

7-104.17 CONVICT LABOR (74 APR) 

7-104. 20(a) UTILIZATION OF LABOR SURPLUS AREA CONCERNS (70 JUN) 

7-104. 21(a) LIMITATION OF WITHHOLDING OF PAYMENTS (58 SEP) 

7-104.23 (a) SUBCONTRACTS (74 APR) 

7-104. 35(a) PROGRESS PAYMENT FOR OTHER THAN SMALL BUSINESS 
CONCERNS (74 SEP) 

7-104. 36(a) UTILIZATION OF MINORITY BUSINESS ENTERPRISES (71 NOV) 

7-104.39 INTEREST (72 MAY) 

7-104.40 COMPETITION IN SUBCONTRACTING (62 APR) 

7-104. 41(a) AUDIT BY DEPARTMENT OF DEFENSE (74 APR) 

7-104.77 (f) GOVERNMENT DELAY OF WORK (68 SEP) 

7-104.82 PAYMENT OF INTEREST ON CONTRACTORS' CLAIMS (72 MAY) 

7-302.2 PAYMENTS (59 JUN) 

7-302.3 STANDARDS OF WORK (59 JUN) 

7-302. 4(b) INSPECTION (59 JUN) 

7-302. 9(a) DEFAULT (69 AUG) 

7-302.21 , AUTHORIZATION AND CONSENT (61 JAN) 

7 -302. 23(b) PATENT RIGHTS (LICENSE) (69 DEC) 

7-304.1 CHANGES (65 JUN) 

7-404.6 REPORTS OF WORK (60 JUL) 

7-2003.41 ORDER OF PRECEDENCE (73 APR) 

7-104.18 PRIORITIES, ALLOCATIONS, AND ALLOTMENTS (74 APR) 
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1. Introduction 

This final report will describe the work performed by 
COMSAT under ARPA contract No. F44620-74-C-0070 , Order No. 2298. 
The purpose of the contract was to assist ARPA in extending the 
ARPANET to countries overseas from where seismic data would be 
returned to SDAC. The transmission technique to be employed 
would be packet switching via satellite, once the technique had 
been proven through an experimental program. It was towards the 
implementation of this experimental program that the effort was 
directed during the contract period. 

A meeting waj held in London in January, 1975, with 
representatives of ARPA, Bolt Beranek and Newman, COMSAT, and 
the 3ritish Post Office. Its purpose was to discuss the imple- 
mentation schedule of the proposed packet-switching experiment 
between the U.S. and U.K. The date of July 1, 1975, was set as 
a target date for the start of transmission between the earth 
stations at Etam, W. Va. , and Goonhilly, U.K. 

This report is divided into six sections. The first 
is the introduction, the second will describe the system operation 
including the operation of the SPADE channel units. The third 
section will describe the operation of the interface unit, and 
the fourth section the operation of the data test set. Section 5 
shows the system integration, and Section 6 is the conclusions. 

The two major accomplishments under this contract were 
the design and construction of breadboard models of the SIMP /SPADE 
Interface Dnit (SSI) and a Data Test Set (DTS) . The SSI is in- 
stalled between the SIMP and the SPADE channel units. It is used 
for controlling the SPADE channel carrier turn-on and turn-off 
times relative to the transmission of data from the SIMP, provide 
clocking pulses from the SPADE channel unit to the SIMP for both 
the transmission and reception of data, and to perform other 



functions necessary for the proper operation of the SPADE channel 
unit in a burst transmission mode. The DTS can be used to perform 
a number of functions, among them are the measurement of Bit Error 
Rates, testing of the modified SPADE channel units for proper 
operation, and monitoring of a standby channel unit to ensure op- 
erational readiness. 

2. System Description 

Figure 1 shows the system conf iauratior. as it will 
exist at the earth station. Data to be transmitted will enter 
the earth station via terrestrial network, '. erminating in a 
Western Electric Company model 3 03C, 50 KB/s Data modem. At 
earth stations not serviced by ATT, Internation Standard V.35 
modems would be employed. The data is then fed from the modem 
directly to the SIMP. The SIMP re-forms the data into packets 
suitable for transmission through the INTELSAT Atlantic Region 
Primary satellite employing the burst mode capability of the 
SPADE terminal channel units. All receive data from the satellite 
is passed by the channel unit to the SIMP where it is reassembled 
into its original format and sent to its destination via the 
terrestrial network as described above. 

Since the INTELSAT SPADE terminal provides PCM coded 
voice circuits at a rat' of 56 KB/s using burst mode 4* PSK 
transmission, it was proposed by COMSAT to modify SPADE channel 
units for the experimental program and operate into the SPADE 
satellite transponder, rather than develop a new satellite modem 
and transmission system. 

It should be noted here that packet data system operation 
requires that two SPADE channel units at each earth station be 
modified, since all stations in the network will share the same 
carrier frequency through the satellite. In normal SPADE system 



operation, a single channel unit is used to provide a full duplex 
voice circuit through the satellite with send and receive carrier 
frequencies separated by 18.045 MHz. However, in the satellite 
packet switching concept which has been developed by ARPA, all 
stations must transmit and receive on the same frequency. There- 
fore, two channel units are required, turned to frequencies 
18.045 MHz apart. While this configuration seems wasteful of 
equipment, it does have the advantage of providing a complete 
spare set of transmit and receive units. 

In the following paragraphs, the operation of the ■ 
SSI, and SPADE channel units will be dei „ed. A detailed de- 
scription of the operation of the SSI is presented in Section 3. 

2.1 System Operation 

The SPADE system was originally designed to convert 
4.0 kHz terrestrial voice band analog signals to 56 KB/s PCM data 
using 7 bit encoding at an 8 kHz sampling rate. For packet data 
operation the SIMP will substitute data for PCM voice and will 
transmit its data at 56 KB/s to the SPADE onannel unit, ana receive 
its data also at 56 KB/s. The SPADE PCM voice CODEC is bypassed 
and the data fed directly into the Transmit Synchronizer and 
received directly from th_ Receive Synchronizer. Figure 2 is a 
simplified block diagram of the modified Transmit Synchronizer. 

During normal operation, data will be transmitted in 
burst, where each burst can vary in length from as little as 100 
bits to more than of 1000 bits of data. The time between bursts 
will also vary. The exact format is dependent upon the particular 
system protocols which are determined by the software to be pro- 
grammed into the SIMP. 



When the SIMP is ready to transmit a packet of data, 
it sends a CARRIER ON (GO) signal designated as GOSIG, to the 
interface unit. The SSI generates two signals from the GOSIG, 
viz. , CARRIER ON/OFF and CARRIER GATE* which are passed to the 
SPADE Transmit Synchronizer. The former signal is used to turn 
ON the SPADE channel carrier prior to the transmission of data. 
The latter starts the CARRIER ON SYNCHRONIZER which generates a 
series of pulses referred to as the PREAMBLE and Start of Message 
(SOM) sequences. These data bits are used in reception for carrier 
li-nveiy, bit timing recovery, and synchronization. In addition, 
a Start Preamble pulse <5^) is also generated and sent to the 
SSI. This pulse causes a gate within the SSI to open, allo.v^..y 
56 kHz transmit clock pulses to be sent back to the SIMP. Data 
is sampled out of the SIMP synchronous with the clock pulses. 
The first data bit is coincident with the SP pulse. The data is 
sampled out of the SIMP at 56 Kfl/s and fed to the Transmit Syn- 
chronizer in the SPADE channel unit. When the last data bit has 
been sampled out of the SIMP, this GOSIG goes off, turning off 
the gate in the SSI, and stopping any further clock pulses from 
being sent to the SIMP. 

The data which are fed to the channel unit is written 
into two 112 bit read/wr 1 te memories. As the data is written into 
the first memory at 56 KB/s, the Preamble and SOM are generated 
and transmitted to the channel modem at a bit rate of f KB/s. 
Once the first memory has been filled, data is then written into 
Memory 2. While data is being written into Memory 2, the data is 
read out of Memory 1 at a bit rate of 64 KB/s. When Memory 1 is 
empty, Memory 2 will start to read out, and Memory 1 will have 
data written into it. The SOM is inserted before Memory 1 starts 
to write out its data. The timing is such that 224 bits of data 
at 56 KB/s is equal in transmission time to 256 bits of data at 
64 KB/s, (224 bits of data plus 22 bits SOM = 256 Bits.) This 
sequence is shown in Figure 3. The 64 KB/s serial data is converted 



to two paraliel 3 2 KB/s data streams for modulation of the carrier; 
4*-PSK modulation is used with channel spacing of 45 kHz, and a 
noise bandwidth of 3B kHz. 

The transmitted carrier must remain on until all data 
has been read out of the 112 bit memories. This is accomplished 
in the SSI by employing two sets of counters. The first counts 
the number of data bits sampled out of the SIMP and passed on to 
the channel unit. This counter operates at 56 KB/s. The second 
counts the number of data pulses read cut " c . the memories and 
counts at 64 KB/s. When the second counter reaches the same number 
as the first, t..a Carrier is turned off. The second counter is 
gated off during the 0.5 msec when the SOM is inserted into the 
bit stream, and gated on during the 3.5 msec while the data are 
read out of the memories.' 

When the data are received from the satellite, the 
inverse process is performed, i.e., the 4$-PSK carrier is demodulatec 
into two 32 KB/s parallel bit streams, reformed into a 64 XB/s 
serial bit stream, read into two 112 bit memories at 64 KB/s, and 
then written out of the memories at 56 KB/s. The SOM is stripped 
out of the bit stream during this operation. The operation of the 
Receive Synchronizer is controlled by the CARRIER ON gate gen- 
erated in the receive synchronizer. This gate allows the Read/ 
Write memo-ies to operate only as long as the carrier is present. 
To accommodate timing delays within the receive synchronizer, a 33 
bit delay in addition to the 112 bit delays in the read/write 
memories, the transmitted carrier must remain ON sufficiently long 
to ensure all memories have been cleared of received data. This 
requires the transmitted carrier to be ON for approximately 2 . 5 msec 
after all data has been cleared out of memories in the transmit 
synchronizer. The design has been verified by performing numerous 
data transmission tests using the data test set, interface unit, 
and the SPADE terminal at the Etam W. Va. , earth station. The 



carrier is held on for this additional time by presetting the 
56 KBit counter in the SSI to 140. More extensively testing 
will be performed to determine the minimum time the carrier 
must remain on to ensure no loss of data. 



2.2 Interface Signal Characteristics 

Figure 4 ia a diagram showing the signals which are 
exchanged among the SIMP , SSI, and the SPADE channel unit. The 
interface between the terrestrial network and the SIMP is a 
digital data modem which passes 50 KBit data and clock co tl.= 
SIMP, where it is stored, divided into packets, and then trans- 
mitted to the SPADE channel unit. 

The signal levels froi,i/to the SIMP on the terrestrial 
and the SPADE side are compatible with the Western Electric Company 
303C modem. On the SPADE side a change of levels is necessary for 
the signals to be compatible with the DTL/TTL levels of the SPADE 
channel unit. This level conversion is accomplished within the 
interface unit. The WECO 303C modem levels are defined as: 

a. binary "1", control "OFF", or "marking" 
signal is represented by a current less 
than 4 ma into 100 ohms ; 

b. binary "0" control "ON", or "spacing" 
signal is represented by a current 
greater than 23 ma into 100 ohms. 

The signal levels to and from the SPADE channel unit 
are DTL/TTL logic, and are defined as: 

a. logical "1" is a positive voltage greater 
than 2.4 volts; 

b. logical "0" is a positive voltage less than 
0.4 volts. 
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A total of six signals are exchanged between the 
SIMP and the SSI. They are: 

a. GOSIG — a binary "0" gate from the SIMP 
to the SSI indicating when data are to be 
transferred from the SIMP to the SPADE channel 
unit. The gate goes off, i.e.,, returns to 
binary one after the last data bit has been 
sampled. 

b. XMIT Data— the 56 KB/s data to be trans- 
mitted. Binary "0"'s or "l"'s are sent from the 
SIMP to the SSI. 

c. 56 kHz XMIT CLK--clock pulses used to syn- 
chronize the sampling of data from the SIMP. The 
clock pulses originate in the SPADE Transmit Syn- 
chronizer, and are converted to 303C levels in 
the SSI. The data pulses are changed during the 
positive transition of the clock pulse; i.e. , 
transition from binary "1" to binary "0", and 
sampled by the SSI during the negative going 
transition of the clock pulse. The clock, pulse 
width is 2.23 usee. 

d. RCVE Data — The 56 KB/s data received by 
the SSI from the SPADE Receive Synchronizer and 
transmitted to the SIMP after conversion to 303C 

e. 56 kHz RCV CLK — clock pulses used to syn- 
chronize and transmit the Receive Data out Of the 
SPADE Receive Synchronizer. The clock pulses are 
generated in the Receive Synchronizer Unit and are 
continuously transmitted to the SIMP through the 
interface unit. Conversion to 303C levels is per- 
formed in the SSI. 



f. Crosspatch — a binary "0" gate which provides 
loopback testing of the transmitted data. During the 
crosspatch or loopback test, there is no transmission 
to the satellite. 

The signals exchanged between the SSI and the SPADE 
channel units are: 

a. Carrier On/Off — a logical "0" gate used to 
turn on the 45.9875 MHz IF carrier in the 4* PSK 
modem. 

b. Carrer Gate — a logical "1" gate to turn on 
the Carrier ON Synchronizer in the Transmit Syn- 
chronizer module, where the Start Preamble pulse 
is generated. It is transmitted from the inter- 
face unit to the SPADE channel unit. 

c. Start Preamble — a logical "0" pulse which is 
used to start sending clock pulses to the SIMP. 
This pulse goes from the channel unit to the inter- 
face unit. 

d. XMIT Data — the 56 KB/s data to be transmitted. 
It is received from the SIMP and converted to TTL 
levels before it is sent to the SPADE channel unit. 

e. XMIT Clock (56*! >— 56 kHz clock pulses sent 
from the SPADE channel unit to the interface unit. 
Used as timing signals within the interface unit. 
One clock pulse is transmitted for each datum bit. 

f . RCV Data—received 56 KB/s data transmitted 
from the SPADE channel unit to the interface unit 
where it is converted to 303C levels before being 
sent to the SIMP. 



g. RCV CI ocX — 56 kHz clock pulses used to syn- 
chronize the received data being transmitted to the 
SIMP. The clock pulses are converted to 303C levels 
before they are sent to the SIMP. 

h. 64 kHz Clock (64$ i) and Memory Output Disable 
(MOD) --the 64*i clock and MOD are used in the counter 
circuits for determining when all data has been trans- 
mitted from the SPADE Transmit Synchronizer. 

A common ground will be established between the SSI 
and SPADE channel units. 

The signal characteristics of the PCM Data and clock 
pulses (items d, e, f, and g) within the Transmit and Receive 
Synchronizers, are as follows: 

a. 56 KB/s Transmit Data are TTL levels, non- 
return to zero (NRZ) with high level of zero, 
low level of one.* 

b. T.56 kHz Transmit Clock pulses are TTL levels, 
low-to-high rising edge with high level pulse 
width of 2.23 usee. The leading edge of the 
transmit data is delayed from the low-to-high 
rising edge by SO to 100 usee. 

c. 56 KB/s Receive Data are TTL levels, NRZ, with 
high level of one, low level of zero. 

d. R.56 kHz RCV Clock pulses are TTL levels, low- 
to-high rising edge with high level pulse width 
of 2.23 usee. The leading edge of the receive 
data is delayed from the trailing edge (i.e., 
high-to-low falling edge) of the clock pulse 

by 100 to 200 nsec. 



*This is the inverse of the logic levels specified earlier. 
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In addition to the above signals, a crosspatch or 
loopback signal is available for test purposes. Insertion of 
the crosspatch signal (a logical "0" at J2-11 of the Receive Syn- 
chronizer} will cause the transmit synchronizer output to be 
connected to the receive synchronizer inputs in the same channel 
unit. This will provide test information to determine whether 
the data are being correctly received from the SIMP, transferred 
to the SPADE channel unit, and transferred back to the SIMP with- 
out errors. During this mode of operation, operational data are 
not transmitted to nor received from the satellite. 

3 . Operation of the Interface Unit (STI ) 

In the following description of the operation of the 
SSI unit, signals are fed to the unit from the SIMP and from the 
Transmit Synchronizer in the SPADE channel unit. Since the opera- 
tion of the Data Test Set is similar to the SIMP, the discussion 
will be limited to the exchange of signals between the SIMP, SSI, 
and SPADE channel unit. References will be made to Figure 5, 
SSI Partial Schematic, and Figure 6, Timing Diagram. Line numbers 
on the timing diagram correspond to signal points (D, ©, (3), etc. , 
on the interface schematic. 

When the SIMP is ready to transmit data, the GOSIG is 
sent from the SIMP to the interface unit. Since the relationship 
between the GOSIG and the 56 kHz clock pulses are arbitrary, FF-1 
in the interface unit is used to synchronize the GOSIG with the 
clock, to prevent the possible loss of synchronization at other 
points within the circuit. 

The delayed pulse, GOSIG* , is applied to FF-4 and the 
8 bit Shift Register S/R-l through FF-3. This second flip-flop, 
FF-3, is to insure synchronization of GOSIG* with the 56 kHz clock. 
The Q output of FF-4 is applied to the Data (D) input of FF-5, 
which is synchronized with the 64 kHz clock. The Q output of FF-5, 
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is applied to the Transmit Synchronizer as the Carrier ON /OFF , 
and will control the ON/OFF time of the 46 MHz carrier in the 4* 
PSK modem. The output of the 8 bit shift register is applied to 
the Carrier ON Synchronizer module in the Transmit Synchronizer. 
One output of the Carrier ON Synchronizer, the Start Preamble. (SP) 
pulse is fed to the interface unit. Once the SP, Q>» is applied 
to FF-2, the 56 kHz clock pulses, @, will be transmitted to the 
SIMP. The first clock pulse to be transmitted is coincident with 
the SP pulse. The purpose of the 8 bit shift register is to allow 
the carrier to be turned on well in advance of the transmission of 
data. This is to allow some time for the receive modem at the 
receive station to lock onto the carrier prior to the detection 
and demodulation of data. In the breadboard model, the 8 bit 
shift register provided 142 usee of delay, and approximately 115 
usee between leading edges of the Carrier ON/OFF and Carrier Gate* 
signals. Higher delay time can be obtained by adding additional 
shift registers, should this prove necessary. 

The approach used to control the turn-off time of the 
carrier is to count the actual number of data bits sampled from 
the SIMP, and then count the number of data bits transmitted 
from the SPADE channel unit. The bottam portion of Figure 5 is a 
simplified schematic of the counter/decoder system. 

In this arrangement, two counters are required: one 
to count the clock pulses sent to the SIMP, and the other to 
count clock pulses at the transmit bit rate of 64 KB/s. This 
second counter is gated with the Memory Output Disable signal 
from the transmit synchronizer. It is high during 224 clock 
pulses, (3.5 msec), after which it goes low for 32 clock pulses, 
(0.5 msec). It is during this short time that the SOM is inserted 
into the transmitted bit stream. Each counter is composed of 
three four-stage counters connected in series. This will allow 
for a maximum count of 409 6 bits. 
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The decoding section is composed of 12 exclusive NOR 
gates which feed a 13 input NAND gate. The output of the NAND 
gate will be high until both inputs to each exclusive NOR gate 
are equal. This will occur only when the 64 Kb counter has 
reached the identical count as the first counter (SIMP clock 
pulses, Q) ■ Vhe output of the NAND gate is held high between 
GOSIG pulses by the output of FF-2 (Q) ;' i.e., when the input 
levels to each exclusive NOR are low. The output pulse (16 ysec 
wide), ^4) will clear FF-4, which in turn will cause the CARRIER 
:::/OFr to go high at the next C4 kHz clock pulse As mentioned 
in Section 2, the carrier must remain on in order to insure that 
ail data will clear the registers in the Receive Synchronic 
upor. reception. This is true whether data are received from the 
satellite or through loopback tests. In order to insure that 
the carrier is kept on sufficiently long, the 56 kHz counter must 
be preset to 140. This corresponds to 2.5 msec, at 56 KB/s. 
Therefore, the decoder ouput will remain high until the 64 KBit 
counter has reached a count of N+140, where N is the number of 
data bits sampled from the SIMP. 

Figure 7(a), 7(b), and 7(c) are photographs taken with 
the Data Test Set and SPADE Transmit Synchronizer operating with 
the SSI. Each figure shows the following signals from top to 
bottom: 

a) 56 kHz clock 

b) GOSIG 

c) CARRIER ON/OFF 

d) CARRIER GATE* 

e) SP 

f) Gated 56 kHz clock to SIMP 

g) Data (from Data Test Set) 

As it was mentioned in the introduction of this report, 
the Data Test Set can be employed to simulate the operation of 
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the SIMP . The GOSIG and Data traces were taken from the Data 
Test Set. The 56 kHz clock and SP were taken from the transmit 
Synchronizer, and the remaining signals from the interface unit. 
In Figure 6 (b) it can more easily be seen that the first clock 
pulse to the SIMP does occur coincident with the SP pulse. The 
data generated by the particular pseudo-random sequence generator 
(PRG) in the Data Test Set, i.e., X 10 -X 3 -l, supplies the first 
seven data pulses as l's, the next three as "O's", followed again 
by four l's, etc. The data is high prior to the SP pulse as a 
result of initializing the PRG prior to transmission or data. 
This is seen to be datmi bit no. 1. In Figure 6(c) it can be 
seen that the GOSIG goes off after the last data pulse has been 
sent out. Also, the CARRIER ON/ OFF is held low for 4.7 msec after 
the GOSIG goes off to insure complete data transmission through the 
Receive Synchronizer. This time increment also allows for approxi- 
mately seven additional receive clock pulses to be sent to the 
SIMP after the last data bit. 

4. Data Test Set 

The Data Test Set (DTS) was specifically developed for 
use in conjunction with the SPADE Transmit and Receive Synchronizers 
and the SIMP/SPADE Interface Unit. It's purpose is to enable 
the earth station personnel to test the modified SPADE channel 
units and the SSI for proper operation, for monitoring the off-line 
channel unit for stand-by readiness , and to measure bit error rate 
performance of the SPADE channel unit in burst mode transmission. 

The test set has a transmit and receive section which 
operate independently of each other. The transmit section receives 
its clock timing pulses from the SPADE Transmit Synchronizer, and 
the receive section obtains its clock timing pulses from the SPADE 
Receive Synchronizer. This allows the transmit and receive sections 
of the DTS to operate independently of each other. Hence, tests 
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can be performed between two or more earth stations in the network, 
in the same manner as one earth station may test and checkout its 
own equipment on a loopback basis. 

It is possible in the DTS to vary the time between bursts 
from as little as 15 iisec up to approximately 5.8 msec. Each burst 
transmits a fixed pseudo-random bit pattern of 1000 data bits. The 
pattern is generated by the polynominal x 10 -x 3 -l. This polynomial 
will generate a random pattern of 1023 bits before it repeats its 
sequence. However, only data bits in the sequence from bit no. 2 
through no. 1001, inclusive, are transmitted in each burst. 

The receive section operates independently from the 
transmit section. Detection of data is performed through a 
unique word detector. The output pulse from the detector causes 
a second pseudo- random generator to generate the exact bit pattern 
that was generated in the transmit side. Comparison on a bit-by-bit 
basis is used to determine the bit errors that occur. A second 
counter is used to count the number of bursts that were received. 
Knowing the number of bursts and the number of bit errors generated, 
the bit error rate can be determined. 

Indicator lights are used to show when data is being 
transmitted and when the receiver has acquired and locked-on to 
the received data. Switches are available to start and stop data 
transmission, and to stop the readout counters for bit error rate 
calculations. 

5. System Configuration 

Figure 8 shows how the SIMP, SSI, DTS , and SPADE channel 
units will be connected into an integrated system at the earth 
station. In this configuration two SSI's are required, one for 
operation with the SIMP and the on-line transmit and receive 



synchronizers, and the others SSI for operation with the DTS and 
off-line transmit and receive synchronizers. The switch matrix 
is provided so that in the event of a failure of any unit in the 
system, switch-over to the standby units can be accomplished with 
a minimum interruption of service. Provisions have been made 
for performing loopback tests from the SIMP, DTS, or SPADE channel 



During normal operation the SIMP will be connected to 
transmit synchronizer A and receive synchronizer A 1 through the 
SSI A . The DTS will operate with transmit synchronizer A' and 
receive synchronizer A through SSIg. The connection of the SIMP. 
DTS, and SSI's can be interchanged through the operatior. of the 
switch matrix. If loopback tests are to be performed, then all 
signals from one channel unit will be passed through one interface 
unit to the SIMP, while all signals from the second channel unit 
will oe passed to the DTS via the other interface. Table I shows 
all the possible combinations that can be obtained. 

During loopback testi-.g, there will be no transmission 
to or from the satellite from the terminal. It should be noted 
that if loopback tests are to be performed by the SIMP, then the 
DTS will also be connected into a loopback mode. 

6. Conclusions 

The breadboard models of the SIMP/SPADE Interface Unit 
and Data Test Set have been built and tested with the SPADE terminal 
at Etam, W. Va. , and has operated satisfactory. No tests have yet 
been performed with the SIMP connected into the system, and hence, 
no prediction can be made as to whether proper signal levels and 
timing will be achieved without some redesign or adjustment of the 
interface unit. However, it is believed that any changes that may 
be required will be minimal, and little or no delay should occur in 



the schedule for the planned packet switching experiment between 
the U.S. and U.K. planned to begin July 1975. 
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Figure 7 Signal Exchange between 
DTS, SSI, and XMIT SYNC. 
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Dear Dr. Kahn: 

This tetter Is a confirmation and follow up of our previous conversations 
concerning the interconnection of ARPANET and TYMNET. 

The experimental connection that was used during the recent ICCC'72 
demonstration has created much interest in the area of network crossover 
technology. Since this will undoubtedly be of great value to future 
data services, It seems logical to continue the experiment. 

Since the software already exists to facilitate the interconnection of a 
TIP at NASA Ames and a TYMSAT at the same location it would be a small 
undertaking to re-install the software which would allow us to continue 
research In this vital area. 

I have had interest expressed to me directly for the continued inter- 
connection of the two networks from ARPA, NASA/AMES, SRI, Stanford, BBSN, 
and NLM. 

I sincerely believe that by continuing this experimental interconnection of 
the two networks (ARPANET and TYMNET) that we can gain considerable useful 
knowledge in the network crossover area having to do with computer-to- 
computer, computer-to-termlnal and terminal -to-computer technology. 

If you agree with my logic would you please have the proper software 
installed in the NASA/ AMES TIP so that we can continue this research. 



Max P. Beere 
Director of Telecommunications Systems 
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INVESTIGATION OF INTERNET WORKING TECHNIQUES 



FOR PACKET SWITCHED CO''"U N I CAT 1 0 K J5 



by 



Peter T Kirstein 



ABSTRACT: This proposal outlines a five year project 

investigating problems in interworking between 
packet switched networks. The proposal is for 

a no-cost contract with the ' US Defence 

Advanced Project Agency (DARPA), and is in 

support of another collaboration project 

between DARPA and the UK Royal Signals 
Research Establishment (RSRE). 



I. INTRODUCTION 



university College 1 
research under an agreement with DAP PA since 1973. 
contract ( He-0»74-C-«?28CJ) was originally from 1973 to Seo 
19/5. Under this contract, UCL measured the perform, 



connection to ths LIS A n PAN ST. Ke connected in a nxmber of host 
computers by a then unique front-end technique, and resolved ssnv 
problems of a management kind in order to enable international 
use;? via public common carrier equipment. Finally we set up a 
mechani sm for supporting collaborative usage between research 
groups in the US and the UK. This work was described in a number 
of reports in particular Ref. I. Eventually this contract was 
renewed for one further year to put the usage side on a firm 
footing, and prepare for the Packet Satellite Experiment, and for 

described in Hef.2. From October 1 1976 there was a new contract 
N0ii377-3-0ii05. Under this contract UCL has done substantial 

participated actively in the internetwork activities, and has 
maae preparations for a simple version of a facsimile service 
which could run over Arpanet and Satnet. 

This work is described in detail in Refs 3-6, but a brief 
summary is given in Section 2. Partially as a result of the UCL 
activity, an agreement was made between the UK '.'OD and DARPA on a 
longer term project between the two bodies. The relevant details 
of this agreement are discussed in Section 3. One aspect of that 
agreement is the continued access of the UK to Aroenet and Satnet 
facilities. It has been agreed mutually that UCL is the natural 
location to provide this access. In Section 4 we describe 
briefly the type of research work we eypect to do during 1982 and 
1933, both in order to comolete this work and to orovide the 
access which is part of the DARPA .tOD agreement. DAPPA-f urni shed 
equipment will be required. In Section 5 we list the eouiprr-ent 
currently in the UK or scheduled to be orovided under the 
Finally, in Section 6, we outline th» effort and 
: which we expect to orovide as part of this 



?.. n&tut ua Results 



i detailed discussion of UCL results are given in Pefs 1-6. 

very significant activity was the user level measurements of 
ist which we have performed. These measurements have be»n 
ribed in Ref. 4 but also in a number of other papers, e.g. 

7-14. The measurements identified serious deficiencies in 



Satnet and a UK experimental packet switched se rv i ce . ( EPSS) . 
This connection was provided in a sufficiently robust way that it 
became standard for the majority of UK users to access Arpanet 
either through EPSS or from another star network based on the 
Rutherford Laboratory. Little usage came directly via the P"blic 
Switched Telephone Network (PSTN) to the TIP. As a result of 
this work we have also identified a number of serious problems 
and .uiSLStches of protocol. ".any of these hirge around 
connecting together systems which were not designed for this type 
of interconnection. An example is the problem with full duplex 
working and not using local echo. The problems 3r" rooted in the 
fact that certain of the operating systems (e.g. Tops 2P and 
lenex) are used heavily in Arpanet, though they were designed for 
local usage. Their use over low delay networks like Arpanet is 
still tolerable! their use over commercial packet switched 
networks or satellite ones siny become inefficient, costly and 
inconvenient. The types of problem and difficulty encountered by 
the interconnection of EPSS and Arpanet affected also the 

: performance of Satnet. Although this work is described in Refs 3 

■and 4, a paper on it is given as Ref. 15. 

; As a result of the practical problems encountered, we have 
made a detailed theoretical analysis of the connection of packet 
'switched networks. Some of the general considerations on the 
different levels of interconnection are described in Refs 16 and 
: 17. A clear theoretical problem identified has been the 
variation in performance caused by different flow control, 
fragmentation and buffering strategies. Analyses of these 
phenomena are given in Refs 18-21. 

The PTTs have now standardised on the X25 virtual call 
protocol for access to public data networks. Vie have been 
developing X25 interfaces to Satnet in such a way that users on 
; the British X25 net will be able to access Arpanet via Satnet 
. (Ref. 22). At present we have demonstrated our capabilities by 
ting (terminally at the UK Royal Signals Research 
'•r.^-v '.., a an access protocol which is X25 level 2. 

e full X25 to virtual call transformations 
els of protocol, will be developed during 



3. THE DARPA-. iOD Rh^APCH AGP EE v.H NT 

Partly arising out of the JCL work, which has also been 
supported by the UK v.inistrv of Defence (V.OD), a number of 
examples of collaboration have been dev<=looed between the UK MOD 
and DCD. For instance, there is evteosive collaboration between 
the OK Atonic Weapons Research Kstablls.Vnent ( Af.'Pc ) and the US 
Seismic Oats Analysis Centre CSDAC) on the Analysis of Seismic 
events. Another collaboration has been between the UK RSRE and 
its contractors, in connection with the DOD/DARPA work on the Ada 
language for real-time computing. Another UK f.-'OD croup has 
collaborated with the US Defence Readiness Command (DAROO'O on 
the use of message systems for administrative purposes. Finally, 
RSRE has connected its packet switched network (PPS.M) to the 
DARPA Internetwork Catenet using Internet Protocols. 

In view of the Increasing requirements for DOD-MOO 
collaboration, an agreement has been -ade between RSHE Au<i DARPA 
under' the auspices ofjthe Technical Cooperation Programme (TTCP). 
The important aspects of that agreement for the purposes of this 
proposal are the following! 

(i) The ajreement covers the period July 1 979 to June I934. 

( ii ) MOD will pay for theii 

US and Norway. ° 

ii) MOO will provide sufficient financial support for 

Professor Kirstein and his team at UCL to continue 

active R & D on tooics of mutual interest to both RSRE 
and DARPA , and to operate the Arpanet TIP. Satnet gateway 

v) The UK will interface the P3RE PPSN to Satnet via a 
gateway. and will make one or more general ourpose 
machines ava i laEle "a s hosts on the RSRE PPSN or other UK 



In view of this agreement between .'.10D and DARPA it is necessary 
to continue a subsidiary arrangement between DARPA and UCL. 



4. PROPOSED UCL ACTIVlTlhS 1S8I--36 



The nature of the UCL activities must be expected to chance 
between now and 1986. One aspect of it will clearly be to 
continue to provide the support necessary to MOD to ensure access 
to the Satnet facilities. A number of reports have been written 
on how UCL is proposing to provide this access. A fairly rjood 
description is given in several reports (Kefs 3d- 33). Here we 
have identified the various protocol translations that must be 

. achieved, and the service provisions required. As a result of 
the technical analysis we have then proposed specific 
implementation strategies for terminal (Ref. 34), File and 

: .Message Transmission (Ref. 35). In the process of plannino. we 

' have identified key problems such as access control (Pef . 36) and 

■ addressing. 

Central to the UCL aporoach is the use of a local high so eed 
Ring network for interconnecting the various vide area networks. 
A description of the past UCL work with this network is riescrib-d 
in P.'efs 37 and 33. There has been a very substantial effort in 
ring protocols, and in consideration of how the Sinn will be used 
in this context. The olans for connecting in SAT'-'HT are 
described in Ref. 39. Sasicallv the various wide-area networks 
will all be attached to the UCL Sings, and processing elements on 
the Rings will provide the protocol conversion. message and 
access control services. 

would expect to participate actively in the research aspects of 
what should be provided. So far the gateway provided to SATNET 
is the datagram gateway running Arpanet Host/Access and X25 level 
2. In view of the potential interest in inter-operabi 1 ity 
between civil and defence networks we will provide also a Virtual 
Call X2S level 3 based Gateway in addition to the datagram 
internet gateway to Satnet. Because the US defence r 
use versions of the Internet Protocol TCP, while this 
to happen for the public data networks, c 
virtual call gateway will be a translation between TCP and a 
simple transport service above X25. I'-'e also intend to look at 
the corcpatabi lity of different terminal protocols, and implement 
appropriate mappings between the Arpanet Telnet and those on the 
Public Data Networks. <\'e note this class of problems is also of 
some interest to the US Defense Communication Agency. Some of 
their recent study contracts have involved interoperability of 
Defense and Public networks. 

We expect to continue to participate in measurement activities 
id improve the performance of the Internet 
An example of our measurement plans is givgn in Ref. 



ARPA SUPPORT 



DARPA 
Secti, 
n DARPA - 




Schedule of EquipTent 
1 Honeywell 316 TIP 
I Honeywell 315 S I MP 
1PDP 1 1/35 Gateway 
I LSI- 11 Port Expsnrlsi 



1 C73 or MC 681*23 Gateway October 1982 

Table 1. Schedule of Equipment on Loan froti DAPPA 



This figure also shows the equipment currently oroposed for 
i delivery later In 1981 and 1932. We would expect our actual 
j requirements to change over the course of the next few years, 
I demanded by the collaborative agreement and change in the DAPPA 
! programmes in which we participate. 

j Although we use many JK computer resources in our work, it is 
! also necessary to use US resources. This is partly because much 
of the software developed is done in different research groups 
working on the DAR^A program. les, and interchange and mutual 
extension of the software are absolute requirements. We would 
; expect continued access to computing resources in the US to be 
■ provided in accordance with the strict limits imposed hitherto. 

; This agreement should extend over the period until November 3kJ 
/ 1986 unless the MOD-DARPA agreement is terminated before that 
/ s time, and DARPA therefore wishes to terminate the agreement. 
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7. PES SO '■!,'.'£ L 

As part of our agreement with RSRE, we would expect to have 
three people employed on work relative to this proposal at least 
up to the end of 1984. Our personnel beyond that period would 
depend on the renewel of the agreement with RSRE. 

This agreement does not propose any compensation from DARPA to 
JCL. with two exceptions. First, w? would expect the loan with 
no charge to UCL of the US equipment mentioned in Section 5. 
Second, our participation in the DAPPA Internet and other working 
grouos will usually be at the invitation of DARPA. 



8. REPORTS 

fie would expect to continue to provide short quarterly reports 
and more detailed annual reports, and to make available as in the 
past copies of technical reports and publications produced by the 
INDRA -group to the people specified by DARPA. 
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